If absolute space required isn’t a big concern, you can get halfway there with compound indices. Imagine the classic employee table with fat rows.
(ID integer, name varchar, title varchar, salary real, email varchar, phone varchar, ...)
Your performance sensitive email all the employees job can’t waste time seeking disk heads over the extra data just to retrieve ID and email. So you create an index
index id_email on (ID, email)
If the database is smart, selecting just the ID and email columns will use the index instead of the table.
Of course, ymmv and I’m sure there are entire blogs devoted to explaining why you shouldn’t do this. :)
It’s not that you shouldn’t, after all you can do the same thing with BDB or direct file I/O. The point of columnar databases (and non-columnar databases, for that matter) is to expose an easy-to-use abstraction that hides the implementation (and in this case, disk layout) details. So sometimes it’s just easier to use a columnar database than to make a non-columnar database do what you want.
You can hammer a nail in with the butt of a screwdriver, but an actual hammer makes it a lot easier because that’s what it was built to do. Similarly, you’d have a hell of an annoying time turning a screw with the claw of a hammer.