On Mon, July 2, 2007 22:17, Gregory Stark wrote:
> The way you described it there were records being inserted and later
> deleted.
> Why wouldn't you need vacuums?
>
> Or are all the records eventually deleted and then the table truncated or
> dropped before the next batch of inserts?
In a nuthsh
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> Actually, come to think of it, I don't think I'd want any vacuums at all
> on this particular table. Just the analyze on the primary key, no
> vacuums, no statistics on anything else. Unfortunately it's not just one
> table, but a set of tables
On Mon, July 2, 2007 18:15, Gregory Stark wrote:
>> So I suppose the planner has a good reason to ignore the index at that
>> point. I'm assuming that this is something to do with the correlation
>> between the index and the column's statistics degrading in some way.
>
> Best to post "explain ana
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> So I suppose the planner has a good reason to ignore the index at that
> point. I'm assuming that this is something to do with the correlation
> between the index and the column's statistics degrading in some way.
Best to post "explain analyze
Hi all,
I've run into a case where I get bad performance that doesn't sound too
hard to solve. Question is: is it worth solving?
The situation is this: I have a table that can grow to a large number of
rows, then shrink to zero over a large number of quick, consecutive
transactions. The primary
