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
--
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
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
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
--- 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
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
