Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, David Geier <geidav(dot)pg(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes
Date: 2022-11-18 03:55:14
Message-ID: CAMbWs4_v47mP3VCoqo=7GjL59rDnYPDokCqjHKsJ+gbeRY4bqA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 18, 2022 at 9:36 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Actually, looking at get_attstatslot, I realize it was already designed
> to do that -- just pass zero for flags. So we could do it as attached.

Yes, it is. Using zero flag would short-cut get_attstatsslot() to just
return whether the slot type exists without loading it. Do you think we
need to emphasize this use case in the comments for 'flags'? It seems
currently there is no such use case in the codes on HEAD.

I wonder whether we need to also check statistic_proc_security_check()
when determining if MCVs exists in both sides.

Thanks
Richard

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2022-11-18 04:47:10 Re: Perform streaming logical transactions by background workers and parallel apply
Previous Message Andres Freund 2022-11-18 03:25:23 Re: Strange failure on mamba