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(at)sss(dot)pgh(dot)pa(dot)us>
>To: "Stephen Birch" <sgbirch(at)hotmail(dot)com>
>CC: pgsql-general(at)postgreSQL(dot)org
>Subject: Re: [GENERAL] timestamped archive data index searches Date: Sat,
>20 Jul 2002 15:11:24 -0400
>
>"Stephen Birch" <sgbirch(at)hotmail(dot)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