Re: optimizer choosing the wrong index
От | Merlin Moncure |
---|---|
Тема | Re: optimizer choosing the wrong index |
Дата | |
Msg-id | AANLkTin_-m9wqi0FtEW1i_aFn9cAEANlVAmNchKl5Imo@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: optimizer choosing the wrong index (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: optimizer choosing the wrong index
|
Список | pgsql-general |
On Thu, Jul 8, 2010 at 10:11 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Martin Below <machtin.below@googlemail.com> writes: >> test=# select count(*) total, count(distinct client_id) ids, >> count(distinct expires_on) dates from ps; >> total | ids | dates >> --------+--------+-------- >> 213645 | 123366 | 213549 > > That says the expires_on column is practically unique, which makes me > think the planner is indeed making the right choice. I think so too, but suppose we wanted to force the other plan anyways: select * from ps where (client_id, expires_on) >= ('123', '24.11.2010'::timestamp) and (client_id, expires_on) < ('123', null) order by client_id, expires_on; I'd be curious to see explain analyze (not explain) comparisons for the 'wrong' index vs above. I suspect the plan is 'correct' for *most* of the data, or you cherry picked (or unluckily drew) a bad value to get your 22 times speed difference. merlin
В списке pgsql-general по дате отправления: