Date: Wed, 6 Mar 2019 15:11:55 -0800
From: Andres Freund <andres@anarazel.de>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
	Robert Haas <robertmhaas@gmail.com>,
	Haribabu Kommi <kommi.haribabu@gmail.com>,
	Asim R P <apraveen@pivotal.io>,
	Pg Hackers <pgsql-hackers@postgresql.org>, aagrawal@pivotal.io,
	Dmitry Dolgov <9erthalion6@gmail.com>,
	Alexander Korotkov <a.korotkov@postgrespro.ru>,
	Heikki Linnakangas <hlinnaka@iki.fi>
Subject: Re: Pluggable Storage - Andres's take
Message-ID: <20190306231155.zu6meo7g2pfgieyi@alap3.anarazel.de>
References: 
 <CANXE4TfZUZCg+afo+gpqiHF6O=rDfqt5a+3jTH2SD8FZ9Yd2pA@mail.gmail.com>
 <CAJrrPGc66Bcv5_Lkw+6yqSzptEw2mh8o=JH05poNh4BZYuGN2w@mail.gmail.com>
 <20181127015557.unah7opawwrvr3us@alap3.anarazel.de>
 <20181211021340.mqaown4njtcgrjvr@alap3.anarazel.de>
 <20190121030115.unoxypsx3dxosyeg@alap3.anarazel.de>
 <cb45bbcd-6b5b-e71d-d9cf-f113d57b7498@iki.fi>
 <20190227172931.vxg4kuu7gjcwgz76@alap3.anarazel.de>
 <20190306070721.dd34u7g7ogtlvf7n@alap3.anarazel.de>
 <20190306193324.5gubgbbs6rnaacgv@alap3.anarazel.de>
 <CAKJS1f88j3XmVb4sOVRStXEJbOoXTeTZrEDzSyvWd2a9oDgRVA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAKJS1f88j3XmVb4sOVRStXEJbOoXTeTZrEDzSyvWd2a9oDgRVA@mail.gmail.com>
Precedence: bulk

Hi,

On 2019-03-07 11:56:57 +1300, David Rowley wrote:
> On Thu, 7 Mar 2019 at 08:33, Andres Freund <andres@anarazel.de> wrote:
> > Here's a cleaned up version of that patch.  David, Alvaro, you also
> > played in that area, any objections? I think this makes that part of the
> > code easier to read actually. Robert, thanks for looking at that patch
> > already.
> 
> I only had a quick look and don't have a grasp of what the patch
> series is doing to tuple slots, but I didn't see anything I found
> alarming during the read.

Thanks for looking.

Re slots - the deal basically is that going forward low level
operations, like fetching a row from a table etc, have to be done by a
slot that's compatible with the "target" table. You can get compatible
slot callbakcs by calling table_slot_callbacks(), or directly create one
by calling table_gimmegimmeslot() (likely to be renamed :)).

The problem here was that the partition root's slot was used to fetch /
store rows from a child partition. By moving mt_existing into
ResultRelInfo that's not the case anymore.

- Andres