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 по дате отправления: