Re: [WIP]Vertical Clustered Index (columnar store extension) - take2
От | Jim Nasby |
---|---|
Тема | Re: [WIP]Vertical Clustered Index (columnar store extension) - take2 |
Дата | |
Msg-id | CAMFBP2puR3+6XAabFrHnGMoyRAngqvvRgdmFa+1Gj19_6TL=yA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [WIP]Vertical Clustered Index (columnar store extension) - take2 (Tomas Vondra <tomas@vondra.me>) |
Ответы |
Re: [WIP]Vertical Clustered Index (columnar store extension) - take2
|
Список | pgsql-hackers |
On Fri, May 23, 2025 at 4:29 PM Tomas Vondra <tomas@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...
В списке pgsql-hackers по дате отправления: