Thanks Tom (and others!) Right-on-the-money, as always... By giving it a definitive range I was able to coax query planner to use the index:
SELECT id FROM trans_table WHERE trans_date >= (SELECT current_date::timestamptz) AND trans_date < (SELECT current_timestamp); gave me from midnight to the present... Aside from a slight amount of ugliness, the solution is quite adequate. The subselects shouldn't cause too much overhead, yes? BTW, This didn't work: SELECT id FROM trans_table WHERE trans_date >= current_date::timestamptz AND trans_date < current_timestamp; Which was a "nonconstant" version of the above. I think it still suffers from the timestamp >= unknown_value problem. CG --- Tom Lane <[EMAIL PROTECTED]> wrote: > being careful that both comparison values are nonconstant (don't use > 'infinity'::timestamp, for instance, even though that might seem like > a reasonable thing to do). The planner still has no idea how many rows > will be fetched exactly, but it does realize that this is a range > condition, and its default assumption about the number of matching rows > is small enough to encourage indexscan use. > > Of course this workaround assumes that you can pick an upper bound that > you are sure is past the end of the available values, but that's usually > not hard in the sort of context where you would have thought that the > one-sided inequality test is a sane thing to do anyway. __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
