On Fri, May 23, 2025 at 4:29 PM Tomas Vondra <to...@vondra.me> wrote:
> Also, Alvaro seemed to think TAM is the way to go, and in order to keep > the OLTP performance he suggested to use both heap and VCI at the same > time, in different "forks". I'm not sure how would that work, or if we > can already do that - AFAIK we can't, because ForkNumber does not allow > adding custom forks. We'd have to relax that, or invent some sort of > federated TAM (that just multiplexes it to two TAMs). Maybe. > > But it's not like the IAM approach doesn't need to do this. The first > patch had to add stuff to a lot of random places to make this work. And > some of the places touch stuff that we don't expect indexes to worry > about, like ALTER TABLE, etc. I suspect another option would be to handle this with table inheritance: have one child that is heap-based, a second that's VCI, and a background job to move data from heap to VCI (and vice-versa for updates and maybe deletes). Note that you could actually implement all that in user-space. Personally I'd much rather have a way to do pure VCI / column-store sooner and manage it myself than have to wait another release (or more) to get a complete solution...
