Re: [WIP]Vertical Clustered Index (columnar store extension) - take2

Hello,

I think we need to have a discussion about this patch set. In my
opinion, this is going nowhere in its current form. It's just not
acceptable to have a full-blown executor implementation in contrib/ that
operates based on hooks in heapam and the transaction machinery. This
design doesn't work for us and it can't be accepted.

Which is to say, these continued postings of rebased with minor tweaks
here and there, appear somewhat pointless from my point of view.

So, IMO the discussion we need to have is about setting a development
direction so that this overall project takes a form that can be
accepted. I already proposed upthread and in pgconf.dev last year that
this should be implemented as a new table AM (in src/backend/access/),
and then add appropriate executor support in the main executor code.
If we disagree on this, let's discuss the reasons until we find a
consensus, and then focus on how to use all this code in a way that
works with that design.

Now, I imagine that morphing all this code to become a table AM is a
huge undertaking, so it's going to require buy-in from the employers of
whoever gets to work on it, with (of course) no promise that the project
is going to be successful in the end. In that light, it sounds quite
risky.

Overall, I think a good columnar store is a very important piece that
Postgres is missing. This project appears to be a good way to get that,
so I'd be very happy if it gets done, so I estimate the reward to be
high.

This is just my personal opinion -- other Postgres hackers likely have
different ones. Also, I do not speak on behalf of my employer.

Thanks,

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Industry suffers from the managerial dogma that for the sake of stability
and continuity, the company should be independent of the competence of
individual employees." (E. Dijkstra)