Re: [HACKERS] Pluggable storage - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [HACKERS] Pluggable storage
Date
Msg-id CAA4eK1KWMFBWJdrDB04q1izJ8QZ-Z=PVmQkTdE7agkM3t+zswA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Pluggable storage  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
List pgsql-hackers
On Sat, Oct 14, 2017 at 1:09 AM, Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
> On Fri, Oct 13, 2017 at 9:41 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> On Fri, Oct 13, 2017 at 1:59 PM, Peter Geoghegan <pg@bowt.ie> wrote:
>> >> Fully agreed.
>> >
>> > If we implement that interface, where does that leave EvalPlanQual()?
>
>
> From the first glance, it seems that pluggable storage should override
> EvalPlanQualFetch(), rest of EvalPlanQual() looks quite generic.
>

I think there is more to it.  Currently, EState->es_epqTuple is a
HeapTuple which is filled as part of EvalPlanQual mechanism and then
later used during the scan.  We need to make it pluggable in some way
so that other heaps can work.  We also need some work for
EvalPlanQualFetchRowMarks as that also seems to be tightly coupled
with HeapTuple.


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Pluggable storage
Next
From: Leon Winter
Date:
Subject: Re: [HACKERS] Cursor With_Hold Performance Workarounds/Optimization