"Mitch Vincent" <[EMAIL PROTECTED]> writes:
> Looks like that index scan is very unattractive...
Yes, though not as bad as the cost estimator thinks (almost a 5:1 ratio
in estimated cost, but hardly any difference in real runtime). Still
have some work to do in tweaking the estimates, obviously.
ive... I'll look for some other
ways to speed up the query a bit..
Thanks!
-Mitch
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Mitch Vincent" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, July 21, 2000 1:26 PM
S
"Mitch Vincent" <[EMAIL PROTECTED]> 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..
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
"Mitch Vincent" <[EMAIL PROTECTED]> writes:
> A while back I as told (by Tom Lane I *think*) that timestamp (previously
> datetime) fields couldn't be indexed as such
That's certainly not true now, if it ever was...
regression=# create table applicants(resubmitted timestamp);
CREATE
regression=#
A while back I as told (by Tom Lane I *think*) that timestamp (previously
datetime) fields couldn't be indexed as such and that I should index them
using this method :
CREATE INDEX "applicants_resubmitted" on "applicants" using btree ( date
("resubmitted") "date_ops" );
Since almost all the que
