Re: Planning performance problem (67626.278ms)
От
Tom Lane
Тема
Re: Planning performance problem (67626.278ms)
Дата
Msg-id
500142.1624995808@sss.pgh.pa.us
Ответ на
Re: Planning performance problem (67626.278ms) (Manuel Weitzman)
Список
Дерево обсуждения
Planning performance problem (67626.278ms) Krzysztof Plocharz <plocharz@9livesdata.com>
RE: Planning performance problem (67626.278ms) Igor Neyman <ineyman@perceptron.com>
Re: Planning performance problem (67626.278ms) Krzysztof Plocharz <plocharz@9livesdata.com>
Re: Planning performance problem (67626.278ms) Pavel Stehule <pavel.stehule@gmail.com>
Re: Planning performance problem (67626.278ms) Justin Pryzby <pryzby@telsasoft.com>
Re: Planning performance problem (67626.278ms) Jeremy Schneider <schnjere@amazon.com>
Re: Planning performance problem (67626.278ms) Andres Freund <andres@anarazel.de>
Re: Planning performance problem (67626.278ms) Jeremy Schneider <schnjere@amazon.com>
Re: Planning performance problem (67626.278ms) David Rowley <dgrowleyml@gmail.com>
Re: Planning performance problem (67626.278ms) Tom Lane <tgl@sss.pgh.pa.us>
Re: Planning performance problem (67626.278ms) Manuel Weitzman <manuelweitzman@gmail.com>
Re: Planning performance problem (67626.278ms) Manuel Weitzman <manuelweitzman@gmail.com>
Re: Planning performance problem (67626.278ms) Tom Lane <tgl@sss.pgh.pa.us>
Re: Planning performance problem (67626.278ms) Ranier Vilela <ranier.vf@gmail.com>
Re: Planning performance problem (67626.278ms) Tom Lane <tgl@sss.pgh.pa.us>
Re: Planning performance problem (67626.278ms) Manuel Weitzman <manuelweitzman@gmail.com>
Re: Planning performance problem (67626.278ms) Tom Lane <tgl@sss.pgh.pa.us>
Re: Planning performance problem (67626.278ms) Manuel Weitzman <manuelweitzman@gmail.com>
Re: Planning performance problem (67626.278ms) Tom Lane <tgl@sss.pgh.pa.us>
Re: Planning performance problem (67626.278ms) Manuel Weitzman <manuelweitzman@gmail.com>
Re: Planning performance problem (67626.278ms) Manuel Weitzman <manuelweitzman@gmail.com>
Re: Planning performance problem (67626.278ms) David Rowley <dgrowleyml@gmail.com>
Re: Planning performance problem (67626.278ms) Krzysztof Plocharz <plocharz@9livesdata.com>
Re: Planning performance problem (67626.278ms) Justin Pryzby <pryzby@telsasoft.com>
Re: Planning performance problem (67626.278ms) Pavel Stehule <pavel.stehule@gmail.com>
Re: Planning performance problem (67626.278ms) Krzysztof Plocharz <plocharz@9livesdata.com>
Manuel Weitzman writes: >> On 20-06-2021, at 17:06, Tom Lane wrote: >> So ... the reason why there's not caching of get_actual_variable_range >> results already is that I'd supposed it wouldn't be necessary given >> the caching of selectivity estimates that happens at the RestrictInfo >> level. I don't have any objection in principle to adding another >> caching layer if that one's not working well enough, but I think it'd >> be wise to first understand why it's needed. > For what I could make out from the code, the caching done at the > RestrictInfo level is already saving a lot of work, but there's a > different RestrictInfo instance for each alternative path created by > make_one_rel(). That seems a bit broken; a given WHERE clause should produce only one RestrictInfo. Can you provide a more concrete example? regards, tom lane
В списке pgsql-performance по дате отправления