will have
a brighter
suggestion for you.
What version are you using by the way?
Regards
Mr Pink
--- Jack Kerkhof <[EMAIL PROTECTED]> wrote:
> The query:
> select count(*) from billing where timestamp > now()-60
>
> should obviously use the index
>
> CREATE IN
--- Greg Stark <[EMAIL PROTECTED]> wrote:
>
> Mr Pink <[EMAIL PROTECTED]> writes:
>
> > AFAIK postgres doesn't peek at values used in a query when optimizing
>
> Of course it does.
But not ones returned by a function such as now(), or when you use b
t was possible to do for bind variables (which could change many times in a
transaction)
then it would make even more sense for a stable function which doesn't change for the
life of the
transaction. No doubt this is an oversimplification the situation.
regar
ally related to pg. I'd really like to know more about how pg
treats that
stuff.
regards
Mr Pink
--- Greg Stark <[EMAIL PROTECTED]> wrote:
>
>
> [I'm actually responding to the previous post from Tom Lane, but I've deleted
> it and the archives seem to be down
Not knowing anything about the internals of pg, I don't know how this relates, but in
theory,
query plan caching is not just about saving time re-planning queries, it's about
scalability.
Optimizing queries requires shared locks on the database metadata, which, as I
understand it
causes content
could
just use RAID 1.
It's a pity pg doesn't have a way to use a cluster of servers to get the most out of
your
expensive SAN.
I read a comment earlier about setting block sizes to 8k to math pg's block size.
Seems to make
sense, you should check it out.
Have fun,
Mr Pink
--
