|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Simon Riggs <simon(at)2ndquadrant(dot)com>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Pluggable storage|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2016-08-18 08:58:11 +0100, Simon Riggs wrote:
> On 16 August 2016 at 19:46, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2016-08-15 12:02:18 -0400, Robert Haas wrote:
> >> Thanks for taking a stab at this. I'd like to throw out a few concerns.
> >> One, I'm worried that adding an additional layer of pointer-jumping is
> >> going to slow things down and make Andres' work to speed up the
> >> executor more difficult. I don't know that there is a problem there,
> >> and if there is a problem I don't know what to do about it, but I
> >> think it's something we need to consider.
> > I'm quite concerned about that as well.
> This objection would apply to all other proposals as well, FDW etc..
Not really. The place you draw your boundary significantly influences
where and how much of a price you pay. Having another indirection
inside HeapTuple - which is accessed in many many places, is something
different from having a seqscan equivalent, which returns you a batch of
already deformed tuples in array form. In the latter case there's one
additional indirection per batch of tuples, in the former there's many
for each tuple.
> Do you see some way to add flexibility yet without adding a branch
> point in the code?
I'm not even saying that the approach of doing the indirection inside
the HeapTuple replacement is a no-go, just that it concerns me. I do
think that working on only lugging arround values/isnull arrays is
something that I could see working better, if some problems are
|Next Message||Tom Lane||2016-08-18 16:39:47||Improving planner's checks for parallel-unsafety|
|Previous Message||Tom Lane||2016-08-18 15:30:17||Re: psql: tab completion for \l|