Re: using extended statistics to improve join estimates - Mailing list pgsql-hackers

From Andrei Lepikhov
Subject Re: using extended statistics to improve join estimates
Date
Msg-id 1a741830-f870-4907-80e1-c8455c8fce1d@postgrespro.ru
Whole thread Raw
In response to Re: using extended statistics to improve join estimates  (Andrei Lepikhov <a.lepikhov@postgrespro.ru>)
List pgsql-hackers
On 5/20/24 16:40, Andrei Lepikhov wrote:
> On 20/5/2024 15:52, Andy Fan wrote:
>> +    if (clauselist_selectivity_hook)
>> +        *return* clauselist_selectivity_hook(root, clauses, ..)
> Of course - library may estimate not all the clauses - it is a reason, 
> why I added input/output parameter 'estimatedclauses' by analogy with 
> statext_clauselist_selectivity.
Here is a polished and a bit modified version of the hook proposed.
Additionally, I propose exporting the statext_mcv_clauselist_selectivity 
routine, likewise dependencies_clauselist_selectivity. This could 
potentially enhance the functionality of the PostgreSQL estimation code.

To clarify the purpose, I want an optional, loaded as a library, more 
conservative estimation based on distinct statistics. Let's provide (a 
bit degenerate) example:

CREATE TABLE is_test(x1 integer, x2 integer, x3 integer, x4 integer);
INSERT INTO is_test (x1,x2,x3,x4)
    SELECT x%5,x%7,x%11,x%13 FROM generate_series(1,1E3) AS x;
INSERT INTO is_test (x1,x2,x3,x4)
    SELECT 14,14,14,14 FROM generate_series(1,100) AS x;
CREATE STATISTICS ist_stat (dependencies,ndistinct)
   ON x1,x2,x3,x4 FROM is_test;
ANALYZE is_test;
EXPLAIN (ANALYZE, COSTS ON, SUMMARY OFF, TIMING OFF)
SELECT * FROM is_test WHERE x1=14 AND x2=14 AND x3=14 AND x4=14;
DROP TABLE is_test CASCADE;

I see:
(cost=0.00..15.17 rows=3 width=16) (actual rows=100 loops=1)

Dependency works great if it is the same for all the data in the 
columns. But we get underestimations if we have different laws for 
subsets of rows. So, if we don't have MCV statistics, sometimes we need 
to pass over dependency statistics and use ndistinct instead.

-- 
regards,
Andrei Lepikhov
Postgres Professional

Attachment

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: broken tables on hot standby after migration on PostgreSQL 16 (3x times last month)
Next
From: Peter Smith
Date:
Subject: Re: Pgoutput not capturing the generated columns