Re: speeding up planning with partitions
| От | Tom Lane |
|---|---|
| Тема | Re: speeding up planning with partitions |
| Дата | |
| Msg-id | 8106.1554128954@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: speeding up planning with partitions (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
| Список | 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 по дате отправления: