Re: why doesn't an index help my simple query?

From: Dima Tkach <dmitry(at)openratings(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Bierman <bierman(at)apple(dot)com>, pgsql-novice(at)postgresql(dot)org
Subject: Re: why doesn't an index help my simple query?
Date: 2003-05-31 17:46:24
Message-ID: 3ED8EA70.20006@openratings.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice


>
>>Should the plain 'timestamp' type really default to a different type
>>than what all the rest of the timestamp operators prefer?
>
>
> Tell me about it :-(. SQL92 specifies that "timestamp" means "timestamp
> without time zone", but this is an utterly brain-dead default IMHO.
> You can check the PG list archives if you want to see past flamewars
> about the issue. As a member of the losing side I will gracefully
> retire...
>

But is *this* really the issue here?

It seems to me, that everything would work as expected if the planner
tried to cast the *constant* side of the operator to the column type,
and not the other way around - i.e., in this case, it coverts the
original condition into something like
'time::timestamp with timezone < now ()'
if instead it did
'time < now()::timestamp', it would work, (and be able to use the
index), wouldn't it?

Is there some technical difficulty here, making it too complicated to
implement?

Dima

In response to

Browse pgsql-novice by date

  From Date Subject
Next Message Herbie McDuck 2003-06-01 09:16:12 Me again..nOOb alert
Previous Message Frank Bax 2003-05-31 17:30:59 Re: Examples of accessing postgresql with scripts?