Re: SELECT * FROM t where p or q;
От | frbn@efbs-seafrigo.fr |
---|---|
Тема | Re: SELECT * FROM t where p or q; |
Дата | |
Msg-id | 3BFA95ED.EE814258@efbs-seafrigo.fr обсуждение исходный текст |
Ответ на | SELECT * FROM t where p or q; (frbn@efbs-seafrigo.fr) |
Ответы |
Re: SELECT * FROM t where p or q;
|
Список | 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 по дате отправления: