From: | Виктор Егоров <vyegorov(at)gmail(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: NestedLoops over BitmapScan question |
Date: | 2012-10-01 23:09:44 |
Message-ID: | CAGnEbohb0C279Hm=o8CbDkGK2=ADVgyT0nZtjjdV=J=st6dXCQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Well, I've managed to track down the cause of improper plans.
Due to the data distribution n_distinct had been estimated way too low.
I've manually set it to be 195300 instead of 15500 (with stats_target=200):
select tablename,attname,null_frac,avg_width,n_distinct,correlation
from pg_stats
where (tablename,attname) IN
(VALUES ('meta_version','account_id'),('account','customer_id'));
tablename | attname | null_frac | avg_width | n_distinct | correlation
--------------+-------------+-----------+-----------+------------+-------------
account | customer_id | 0 | 4 | 57 | 0.998553
meta_version | account_id | 0 | 4 | 195300 | 0.0262315
(2 rows)
Still, optimizer underestimates rows returned by the IndexScan heavily:
http://explain.depesz.com/s/pDw
Is it possible to get correct estimates for the IndexScan on the right side
of the NestedLoops? I assume estimation is done by the B-tree AM and
it is seems to be not affected by the STATISTICS parameter of the
column.
2012/9/29 Виктор Егоров <vyegorov(at)gmail(dot)com>:
> Now I have the following plan:
> http://explain.depesz.com/s/YZJ
>
> Second query takes twice more time.
--
Victor Y. Yegorov
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Keller | 2012-10-02 00:15:27 | Re: Inserts in 'big' table slowing down the database |
Previous Message | Colin Taylor | 2012-10-01 21:24:47 | A Tale of 2 algorithms |