With enable_seqscan off (Same query)
Sort (cost=9282.89..9282.89 rows=4880 width=611) -> Index Scan using applicants_created, applicants_resubmitted on
applicants a (cost=0.00..8983.92 rows=4880 width=611)
...and..
! system usage stats:
! 7.541906 elapsed 5.368217 user 2.062897 system sec
! [5.391668 user 2.070713 sys total]
! 1/543 [2/543] filesystem blocks in/out
! 0/9372 [0/9585] page faults/reclaims, 0 [0] swaps
! 0 [0] signals rcvd, 0/3 [4/7] messages rcvd/sent
! 7/101 [12/107] voluntary/involuntary context switches
! postgres usage stats:
! Shared blocks: 0 read, 0 written, buffer hit rate
= 100.00%
! Local blocks: 0 read, 0 written, buffer hit rate
= 0.00%
! Direct blocks: 0 read, 0 written
CommitTransactionCommand
Looks like that index scan is very unattractive... I'll look for some other
ways to speed up the query a bit..
Thanks!
-Mitch
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Mitch Vincent" <mitch@venux.net>
Cc: <pgsql-sql@postgresql.org>
Sent: Friday, July 21, 2000 1:26 PM
Subject: Re: [SQL] Timestamp indexes
> "Mitch Vincent" <mitch@venux.net> writes:
> > select * from applicants as a where (a.created::date > '05-01-2000' or
> > a.resubmitted::date > '05-01-2000') order by (case when a.resubmitted >
> > a.created then a.resubmitted else a.created end) desc limit 10 offset 0
>
> > There is one of the queries.. I just remembered that the order by was
added
> > since last time I checked it's PLAN (in the 6.5.X days) -- could that be
the
> > problem?
>
> Probably. With the ORDER BY in there, the LIMIT no longer applies
> directly to the scan (since a separate sort step is going to be
> necessary). Now it's looking at a lot more data to be fetched by
> the scan, not just 10 records, so the indexscan becomes less attractive.
>
> Might be interesting to compare the estimated and actual runtimes
> between this query and what you get with "set enable_seqscan to off;"
>
> regards, tom lane
>
