Re: Why does a simple query not use an obvious index?
| От | Scott Marlowe |
|---|---|
| Тема | Re: Why does a simple query not use an obvious index? |
| Дата | |
| Msg-id | 1093804128.5493.22.camel@localhost.localdomain обсуждение исходный текст |
| Ответ на | Why does a simple query not use an obvious index? ("Jack Kerkhof" <jack.kerkhof@guest-tek.com>) |
| Ответы |
Re: Why does a simple query not use an obvious index?
|
| Список | pgsql-performance |
On Fri, 2004-08-27 at 11:12, Jack Kerkhof wrote:
> The query:
>
> select count(*) from billing where timestamp > now()-60
>
> should obviously use the index
>
> CREATE INDEX billing_timestamp_idx ON billing USING btree
> ("timestamp" timestamp_ops);
>
> on a table with 1400000 rows.
>
> But it uses a Seq Scan. If I set enable_seqscan=no, it indicates a
> queryplan could not be calculated.
Have you tried this:
marlowe=> select now()-60;
ERROR: operator does not exist: timestamp with time zone - integer
HINT: No operator matches the given name and argument type(s). You may
need to add explicit type casts.
you likely need:
smarlowe=> select now()-'60 seconds'::interval;
?column?
-------------------------------
2004-08-29 12:25:38.249564-06
inside there.
Also, count(*) is likely to always generate a seq scan due to the way
aggregates are implemented currently in pgsql. you might want to try:
select somefield from sometable where timestampfield > now()-'60
seconds'::interval
and count the number of returned rows. If there's a lot, it won't be
any faster, if there's a few, it should be a win.
В списке pgsql-performance по дате отправления: