Re: [HACKERS] Effect of caching hash bucket size while costing
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Effect of caching hash bucket size while costing |
Дата | |
Msg-id | 14581.1481417195@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Effect of caching hash bucket size while costing (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, Dec 8, 2016 at 3:53 AM, Srinivas Karthik V > <skarthikv.iitb@gmail.com> wrote: >> 1) Can you please let me know if innerbucketsize*innerpathrows captures the >> maximum bucket size? >> 2) why is it not calculated afresh all the time? > Well, #2 is answered there right in the comments: > * Since we tend to visit the same clauses > over and over when > * planning a large query, we cache the > bucketsize estimate in the > * RestrictInfo node to avoid repeated lookups > of statistics. > I assume the person who wrote the comment thought that the answer > wouldn't change from one call to the next, and therefore it was safe > to cache. I don't know why that isn't the case for you. That was me. AFAICS, the only way this could change is if virtualbuckets changes, which would require the results of ExecChooseHashTableSize to change, which probably means inner_path_rows changed. So I suspect this got broken by the introduction of parameterized paths; but there's not enough info here to confirm whether we're dealing with a parameterized path or not. If that is it, I wonder whether we could redefine the cached value so that it doesn't depend on virtualbuckets. If not, we could fall back to only using the cache for nonparameterized inner paths. regards, tom lane
В списке pgsql-hackers по дате отправления: