Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes - Mailing list pgsql-hackers

From David Geier
Subject Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes
Date
Msg-id 2a4917f7-8a4d-0094-7189-3a6dcaebad44@gmail.com
Whole thread Raw
In response to Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes
List pgsql-hackers
On 11/18/22 14:00, Tomas Vondra wrote:
> Seems fine. I wonder if we could/could introduce a new constant for 0,
> similar to ATTSTATSSLOT_NUMBERS/ATTSTATSSLOT_VALUES, instead of using a
> magic constant. Say, ATTSTATSSLOT_NONE or ATTSTATSSLOT_CHECK.
Good idea. I called it ATTSTATSSLOT_EXISTS. New patch attached.
> I don't think you can write a test for this, because there is no change
> to behavior that can be observed by the user. If one side has no MCV,
> the only difference is whether we try to load the other MCV or not.

Yeah. I thought along the lines of checking the number of pages read 
when the pg_stats entry is not in syscache yet. But that seems awfully 
implementation specific. So no test provided.

-- 
David Geier
(ServiceNow)

Attachment

pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Glossary and initdb definition work for "superuser" and database/cluster
Next
From: Tom Lane
Date:
Subject: Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes