On 2017-03-21 08:04:11 -0400, Robert Haas wrote: > On Tue, Mar 21, 2017 at 6:56 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > >> Hmm, that test case isn't all that synthetic. It's just a single > >> column bulk update, which isn't anything all that crazy, and 5-10% > >> isn't nothing. > >> > >> I'm kinda surprised it made that much difference, though. > >> > > > > I think it is because heap_getattr() is not that cheap. We have > > noticed the similar problem during development of scan key push down > > work [1]. > > Yeah. So what's the deal with this? Is somebody working on figuring > out a different approach that would reduce this overhead?
I think one reasonable thing would be to use slots here, and use slot_getsomeattrs(), with a pre-computed offset, for doing the deforming. Given that more than one place run into the issue with deforming cost via heap_*, that seems like something we're going to have to do. Additionally the patches I had for JITed deforming all integrated at the slot layer, so it'd be a good thing from that angle as well. Deforming all columns at once would also a boon for the accompanying index_getattr calls. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
