Re: speeding up planning with partitions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: speeding up planning with partitions
Date
Msg-id 8106.1554128954@sss.pgh.pa.us
Whole thread Raw
In response to Re: speeding up planning with partitions  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List pgsql-hackers
Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
> On 2019/04/01 3:46, Tom Lane wrote:
>> One thing that I intentionally left out of the committed patch was changes
>> to stop short of scanning the whole simple_rel_array when looking only for
>> baserels.  I thought that had been done in a rather piecemeal fashion
>> and it'd be better to address it holistically, which I've now done in the
>> attached proposed patch.
>> I have not done any performance testing to see if this is actually
>> worth the trouble, though.  Anybody want to do that?

> Thanks for creating the patch.

> I spent some time looking for cases where this patch would provide
> recognizable benefit, but couldn't find one.

Yeah, I was afraid of that.  In cases where we do have a ton of otherrels,
the processing that's actually needed on them would probably swamp any
savings from this patch.

The only place where that might possibly not be true is
create_lateral_join_info, since that has nested loops that could
potentially impose an O(N^2) cost.  However, since your patch went in,
that runs before inheritance expansion anyway.

So this probably isn't worth even the minuscule cost it imposes.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Extending USE_MODULE_DB to more test suite types
Next
From: Robbie Harwood
Date:
Subject: Re: [PATCH v22] GSSAPI encryption support