Re: bitmap scan much slower than index scan, hash_search_with_hash_value - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: bitmap scan much slower than index scan, hash_search_with_hash_value
Date
Msg-id CAEYLb_U13MFekB_snPwL7gSTpaEJ1rPp2kxVh+jv+e_zqMCnXw@mail.gmail.com
Whole thread Raw
In response to Re: bitmap scan much slower than index scan, hash_search_with_hash_value  (Sergey Koposov <koposov@ast.cam.ac.uk>)
Responses Re: bitmap scan much slower than index scan, hash_search_with_hash_value  (Sergey Koposov <koposov@ast.cam.ac.uk>)
List pgsql-hackers
On 2 September 2012 16:26, Sergey Koposov <koposov@ast.cam.ac.uk> wrote:
> After looking at them, I think I understand the reason -- the
> number of n_distinct for crts.data is terribly wrong. In reality it should
> be ~ 130 millions. I already faced this problem at certain point when doing
> "group by objid" and PG was excausting all the memory, because of that wrong
> estimate. But I know that it's a known hard problem to estimate n_distinct.
>
> So probably that's the main reason of a problem...

That's why we support altering that value with an ALTER TABLE...ALTER
COLUMN DDL statement. You might at least consider increasing the
statistics target for the column first though, to see if that will
make the n_distinct value better accord with reality.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services



pgsql-hackers by date:

Previous
From: Sergey Koposov
Date:
Subject: Re: bitmap scan much slower than index scan, hash_search_with_hash_value
Next
From: Tom Lane
Date:
Subject: Re: Fwd: PATCH: psql boolean display