Re: Timestamp indexes

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
>