Re: Effect of caching hash bucket size while costing

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Dec 8, 2016 at 3:53 AM, Srinivas Karthik V
> <skarthikv(dot)iitb(at)gmail(dot)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