Re: Refactoring of heapam code. - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Refactoring of heapam code.
Date
Msg-id CAB7nPqQJcASE63xhpD6_p5ouUy4Ak+jV_enBh-LSjghsx3cDwQ@mail.gmail.com
Whole thread Raw
In response to Re: Refactoring of heapam code.  (Pavan Deolasee <pavan.deolasee@gmail.com>)
List pgsql-hackers
On Mon, Sep 12, 2016 at 7:12 PM, Pavan Deolasee
<pavan.deolasee@gmail.com> wrote:
> I was thinking about locking, bulk reading (like page-mode API) etc. While
> you've added an API for vacuuming, we would probably also need an API to
> collect dead tuples, pruning etc (not sure if that can be combined with
> vacuum). Of course, these are probably very specific to current
> implementation of heap/MVCC and not all storages will need that.

Likely not, but it is likely that people would like to be able to get
that if some custom method needs it. I think that what would be a good
first step here is to brainstorm a potential set of custom AMs for
tables, get the smallest, meaningful, one from the set of ideas
proposed, and define a basic set of relation/storage/table AM routines
that we can come up to support it. And then build up a prototype using
it. We have been talking a lot about refactoring and reordering stuff,
which is something that would be good in the long term to make things
more generic with heap, but getting an idea of "we-want-that" may
prove to help in designing a minimum set if features that we'd like to
have here.

This would likely need anyway to extend CREATE TABLE to be able to
pass a custom AM for a given relation and store in pg_catalog, but
that's a detail in the whole picture...
-- 
Michael



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: 9.6 TAP tests and extensions
Next
From: Kouhei Kaigai
Date:
Subject: Re: PassDownLimitBound for ForeignScan/CustomScan