Re: strange pg_stats behaviour?
| От | Hubert depesz Lubaczewski |
|---|---|
| Тема | Re: strange pg_stats behaviour? |
| Дата | |
| Msg-id | 20021130080315.GA13989@depesz.pl обсуждение исходный текст |
| Ответ на | Re: strange pg_stats behaviour? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: strange pg_stats behaviour?
|
| Список | pgsql-general |
On Fri, Nov 29, 2002 at 08:04:15PM -0500, Tom Lane wrote: > Hubert depesz Lubaczewski <depesz@depesz.pl> writes: > > # explain analyze SELECT aid, foto FROM auction WHERE data_off < now() - > > # '31 days'::interval; first, thanks for quick reply. > The planner doesn't know what value data_off will be compared to at > runtime, so it has to fall back on a default selectivity estimate. strange - is there no way we can "teach" him, that this is a constant. i mean now() - '31 days'::interval will be exactly the same for all rows of auction, and i belive we could put functionality info planner to "think" about it - right side of my condition doesn't contain any call to table fields, so it probably should be treated as constant value. or am i totally wrong? > Another workaround that you could look at is > SELECT ... > WHERE data_off < now() - '31 days'::interval AND > data_off > '-infinity'; this query looks quite strange, but if it's going to help, then i think i might use it. right now i just modify enable_seqscan before and after my query, but this is definitelly not nice. depesz -- hubert depesz lubaczewski http://www.depesz.pl/ ------------------------------------------------------------------------ Mój Boże, spraw abym milczał, dopóki się nie upewnię, że naprawdę mam coś do powiedzenia. (c) 1998 depesz
В списке pgsql-general по дате отправления: