-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Only some problems that come to my mind with this:
a) Hardware is sometimes changed underhand without telling the customer.
Even for server-level hardware. (Been there.)
b) Hardware recommendations would get stale quickly. What use is a
hardware
Yudhvir Singh Sidhu wrote:
Versions: Postgresql version 8.09 on FreeBSD 6.1
Situation: huge amounts of adds and deletes daily. Running daily vacuums
Problem: Vacuum times jump up from 45 minutes, or 1:30 minutes to 6+
hours overnight, once every 1 to 3 months.
Solutions tried: db truncate -
Steinar H. Gunderson wrote:
On Sat, May 05, 2007 at 09:52:56PM -0700, Yudhvir Singh Sidhu wrote:
Here is what I think the story is:
a. Large amounts of rows are added to and deleted from a table - daily.
With this much activity, the statistics get out of whack easily. That's
where ANALYZE
Hi,
Paul:
Quite like Tom, I too think that its the first query that is more intriguing
than the second one. (The expected cost for the indexscan (A) query is 4x
the expected time for the 'Sequential Scan' (B) query !!)
Could you provide with the (complete output of) EXPLAIN ANALYZE times for
Robins [EMAIL PROTECTED] writes:
There is one thing though, that I couldn't really understand. Considering
that A's correlation in pg_stats being very high compared to B, isn't it 'a
better candidate' for a sequential scan as compared to B in this scenario ?
No, high correlation reduces the
