On Tue, Apr 12, 2016 at 2:27 PM, Andres Freund <and...@anarazel.de> wrote: > none but 2) seem likely to require a substantial compatibility break.
And even that doesn't require one, if you keep the only system around and make the new system optional via some sort of pluggable storage API. Which, to me, seems like the only sensible approach from a development perspective. If you decide to rip out the entire heapam and replace it with something new in one fell swoop, you might as well bother not writing the patch. It's got the same chance of being accepted either way. I really think the time has come that we need an API for the heap the same way we already have for indexes. Regardless of exactly how we choose to implement that, I think a large part of it will end up looking similar to what we already have for FDWs. We can either use the FDW API itself and add whatever additional methods we need for this purpose, or copy it to a new file, rename everything, and have two slightly different versions. AFAICS, the things we need that the FDW API doesn't currently provide are: 1. The ability to have a local relfilenode associated with the data. Or, ideally, several, so you have a separate set of files for each index. 2. The ability to WAL-log changes to that relfilenode (or those relfilenodes) in a sensible way. Not sure whether the new generic XLOG stuff is good enough for a first go-round here or if more is needed. 3. The ability to intercept DDL commands directed at the table and handle them in some arbitrary way. This is really optional; people could always provide a function-based API until we devise something better. 4. The ability to build standard PostgreSQL indexes on top of the data, if the underlying format still has a useful notion of CTIDs. That is, if the underlying format is basically like our heap format, but optimized in some way - e.g. append-only table that can't update or delete with a smaller tuple header and page compression - then it can reuse our indexing. If it does something else, like an index-organized table where rows can move around to different physical positions, then it has to provide its own indexing facilities. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
