Re: Partial index on date column
От | Dave Page |
---|---|
Тема | Re: Partial index on date column |
Дата | |
Msg-id | 50057.80.177.99.193.1046981326.squirrel@ssl.vale-housing.co.uk обсуждение исходный текст |
Ответ на | Re: Partial index on date column (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Partial index on date column
|
Список | pgsql-hackers |
It's rumoured that Tom Lane once said: > "Dave Page" <dpage@vale-housing.co.uk> writes: >> CREATE INDEX pbx_log_today_idx ON pbx_log USING btree (pbx_time, >> pbx_call_type, pbx_digits_source, pbx_digits_destination) WHERE >> (pbx_date = '2003-03-06'::date); > >> I'm surprised by the following behaviour: > >> EXPLAIN SELECT * FROM pbx_log WHERE pbx_date = CURRENT_DATE; >> [ no indexscan ] > >> Is this just an oddity because I don't have masses of data yet (4500 >> rows right now), or is this something the optimizer cannot handle? > > The optimizer does not think that "pbx_date = CURRENT_DATE" satisfies > the partial index's WHERE condition. I don't see any really good way > around this; to improve matters there'd need to be some concept of a > plan that is only good for a limited time. Oh, OK. Thanks Tom. I can obviously work around this in my PHP code, it just struck me as odd. I assume then that the optimizer doesn't execute the function, and that that's done later on? Would the same be true of simple expressions such as 1 + 2? Regards, Dave.
В списке pgsql-hackers по дате отправления: