From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> |
Cc: | Asim R P <apraveen(at)pivotal(dot)io>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, aagrawal(at)pivotal(dot)io, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Subject: | Re: Pluggable Storage - Andres's take |
Date: | 2018-11-27 01:55:57 |
Message-ID: | 20181127015557.unah7opawwrvr3us@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
FWIW, now that oids are removed, and the tuple table slot abstraction
got in, I'm working on rebasing the pluggable storage patchset ontop of
that.
On 2018-11-27 12:48:36 +1100, Haribabu Kommi wrote:
> On Thu, Nov 22, 2018 at 1:12 PM Asim R P <apraveen(at)pivotal(dot)io> wrote:
>
> > Ashwin (copied) and I got a chance to go through the latest code from
> > Andres' github repository. We would like to share some
> > comments/quesitons:
> >
>
> Thanks for the review.
>
>
> > The TupleTableSlot argument is well suited for row-oriented storage.
> > For a column-oriented storage engine, a projection list indicating the
> > columns to be scanned may be necessary. Is it possible to share this
> > information with current interface?
> >
>
> Currently all the interfaces are designed for row-oriented storage, as you
> said we need a new API for projection list. The current patch set itself
> is big and it needs to stabilized and then in the next set of the patches,
> those new API's will be added that will be useful for columnar storage.
Precisely.
> > TupleDelete_function() accepts changingPart as a parameter to indicate
> > if this deletion is part of a movement from one partition to another.
> > Partitioning is a higher level abstraction as compared to storage.
> > Ideally, storage layer should have no knowledge of partitioning. The
> > tuple delete API should not accept any parameter related to
> > partitioning.
> >
>
> Thanks for your point, will look into it in how to change extract it.
I don't think that's actually a problem. The changingPart parameter is
just a marker that the deletion is part of moving a tuple across
partitions. For heap and everythign compatible that's used to include
information to the tuple that concurrent modifications to the tuple
should error out when reaching such a tuple via EPQ.
> Andres, as the tupletableslot changes are committed, do you want me to
> share the rebased pluggable storage patch? you already working on it?
Working on it.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Guo | 2018-11-27 02:07:04 | Re: A WalSnd issue related to state WALSNDSTATE_STOPPING |
Previous Message | Haribabu Kommi | 2018-11-27 01:53:05 | Re: Accounting of zero-filled buffers in EXPLAIN (BUFFERS) |