Re: SELECT * FROM t where p or q; - Mailing list pgsql-sql

From frbn@efbs-seafrigo.fr
Subject Re: SELECT * FROM t where p or q;
Date
Msg-id 3BFA95ED.EE814258@efbs-seafrigo.fr
Whole thread Raw
In response to SELECT * FROM t where p or q;  (frbn@efbs-seafrigo.fr)
Responses Re: SELECT * FROM t where p or q;  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
List pgsql-sql
thanks a lot to pay attention to my problem

thanks to you, after a 15mn long "vacuum ANALYZE table"      :(
the "OR" works now just how  it was supposed to.             
I wrongly thought that a "vacuum" did a "vacuum ANALYZE" by default.


I can't figure out how Tera-bytes databases admins can
deal with such vacuum delays!
(except if a vacuum is only needed every 10 millions records :] )

Best regards,
Franck.

Tom Lane wrote :
> 
> frbn@efbs-seafrigo.fr writes:
> > on a +10 millions rec table, a simple select:
> > SELECT * FROM tab where num = x;
> > time: 5 secondes
> 
> > SELECT * FROM tab WHERE num = x OR num = y;
> > time: more than 10 mn !!!
> 
> What does EXPLAIN show?  Have you VACUUM ANALYZEd the table recently
> (or indeed ever)?  This looks a lot like the behavior on a
> never-vacuumed table --- the default statistical assumptions are such
> that an indexscan looks like a win for one equality clause, but not
> for two ORed clauses.
> 
>                         regards, tom lane


pgsql-sql by date:

Previous
From: Brent Verner
Date:
Subject: Re: INDEXng date_trunc ...
Next
From: Merrill Oveson
Date:
Subject: bug, I think