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

From: David Geier <geidav(dot)pg(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-14 09:19:18
Message-ID: 16acb727-24e8-6453-1711-aae339802966@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Tom,
> There won't *be* any MCV stats for a column that ANALYZE perceives to
> be unique, so I'm not quite sure where the claimed savings comes from.
We save if one join attribute is unique while the other isn't. In that
case stored MCV stats are read for the non-unique attribute but then
never used. This is because MCV stats in join selectivity estimation are
only used if they're present on both columns
> Please provide a concrete example.

A super simple case already showing a significant speedup is the
following. The more ways to join two tables and the more joins overall,
the higher the expected gain.

CREATE TABLE bar(col INT UNIQUE);
CREATE TABLE foo (col INT);
INSERT INTO foo SELECT generate_series(1, 1000000, 0.5);
SET default_statistics_target = 10000;
ANALYZE foo, bar;
\timing on
EXPLAIN SELECT * FROM foo, bar WHERE foo.col = bar.col;

Running the above query five times gave me average runtimes of:

- 0.62 ms without the patch and
- 0.48 ms with the patch.

--
David Geier
(ServiceNow)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2022-11-14 10:10:31 Re: A problem about join ordering
Previous Message Hayato Kuroda (Fujitsu) 2022-11-14 08:58:10 RE: Time delayed LR (WAS Re: logical replication restrictions)