Re: timestamped archive data index searches

ok

I assume that the string 'now' would suffer from the same problem and should
also be avoided until 7.3?

BTW Another thing I notice with a large database is that count(*) takes
ages, it
looks like it has to scan every record. This may be a newbie question or a
faq, but isn't there a record count kept that would make count(*) return
quickly?

Steve

PS I have been using PostgreSQL for about 5 years now in a mission critical
application and have grown to love it. What I can't figure out is how Tom
and the others find time to do such fantastic work!


>From: Tom Lane <tgl@sss.pgh.pa.us>
>To: "Stephen Birch" <sgbirch@hotmail.com>
>CC: pgsql-general@postgreSQL.org
>Subject: Re: [GENERAL] timestamped archive data index searches Date: Sat,
>20 Jul 2002 15:11:24 -0400
>
>"Stephen Birch" <sgbirch@hotmail.com> writes:
> > I also tried the following, which explain said is also using a sequence
>scan
> > :-(
>
> > SELECT sum(vol) FROM det
> >   WHERE tstamp > (current_timestamp - '5 seconds'::interval);
>
>This doesn't work (in 7.2 and before) because the planner doesn't think
>current_timestamp is a constant.  You can get around that with a custom
>function that hides the current_timestamp computation and is marked
>isCachable --- this is a cheat but works well enough in interactive
>queries.  (It'd not work inside plpgsql unfortunately.)  See past
>archived discussions --- searching for isCachable should turn up
>examples.
>
>Beginning in 7.3 there will be a finer-grain notion of constant
>functions so that the planner can optimize this sort of thing as-is.
>
>            regards, tom lane






_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com