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)
