On 2016-08-18 08:58:11 +0100, Simon Riggs wrote: > On 16 August 2016 at 19:46, Andres Freund <and...@anarazel.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 addressed beforehand. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers