On 2017-02-27 19:20:56 +0100, Tomas Vondra wrote: > On 02/27/2017 12:55 PM, Andres Freund wrote: > > On 2017-02-24 15:18:04 -0800, Andres Freund wrote: > > > On 2017-02-24 15:12:37 -0800, Andres Freund wrote: > > > > On 2017-02-24 18:04:18 -0500, Tom Lane wrote: > > > > > Concretely, something like the attached. This passes regression tests > > > > > but I've not pushed on it any harder than that. > > > > > > > > Heh, I'd just gotten something that didn't immediately crash anymore ;) > > > > > > > > Running your patch against Jeff's test-case, verified before that I > > > > could easily reproduce the O(N^2) cost. > > > > > > Oh, that didn't take as long as I was afraid (optimized/non-assert build): > > > > > > postgres=# SET work_mem = '13GB'; > > > SET > > > Time: 2.591 ms > > > postgres=# select count(*) from foobar2 where not exists > > > (select 1 from foobar t where t.titleid=foobar2.titleid); > > > Time: 268043.710 ms (04:28.044) > > > > As another datapoint, I measured this patch against the problem from > > https://www.postgresql.org/message-id/20170227111732.vrx5v72ighehw...@alap3.anarazel.de > > (see top post in thread), and it indeed fixes the runtime issue - > > there's still considerably higher memory usage and some runtime > > overhead, but the quadratic behaviour is gone. > > > > I think we should go forward with something like this patch in all > > branches, and only use Tomas' patch in master, because they're > > considerably larger. > > > > So you've tried to switch hashjoin to the slab allocators? Or what have you > compared?
No, sorry for not being more explicit about this. Meant that Tom's patch addresses the performance issue in the reorderbuffer.c to a good degree (i.e. gets rid of the quadratic cost, even though constants are higher than w/ your patches). As the patch here is a lot smaller, it seems like a better choice for the back-branches than backporting slab.c/generation.c. Andres -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers