On Fri, 1 Oct 2004, Matthew T. O'Connor wrote:
Marc G. Fournier wrote:
On Thu, 30 Sep 2004, Matthew T. O'Connor wrote:
Are you using default values for autovacuum? Could you prove a little
more detail by setting pg_autovacuum debug with -d 2
Sure ... just restarted it with that setup ... btw ...
Marc G. Fournier wrote:
On Thu, 30 Sep 2004, Matthew T. O'Connor wrote:
Are you using default values for autovacuum? Could you prove a
little more detail by setting pg_autovacuum debug with -d 2
Sure ... just restarted it with that setup ... btw ... I'm using -L
for logging ... what is the usual
BTW, seems to be holding up pretty well so far, but I've also reduced, by
half, the baner ads on archives, so its not being hit near as much as it
used to be ...
du 17144
656217144
On Thu, 30 Sep 2004, Matthew T. O'Connor wrote:
Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
You say
On Thu, 30 Sep 2004, Matthew T. O'Connor wrote:
Are you using default values for autovacuum? Could you prove a little
more detail by setting pg_autovacuum debug with -d 2
Sure ... just restarted it with that setup ... btw ... I'm using -L for
logging ... what is the usual way of gettin git to go
Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
You say it's "*very* busy" is it possible there are hundreds or thousands of
tuples in there that are uncommitted or committed after this query starts?
More specifically, I bet there's a huge number of completely empty
pages, which woul
Greg Stark wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Its a *very* busy table ... and running on a 7.4.0 database ...
I wonder how many tuples are really in this table. Almost all of the 190ms is
spent in the two sequential scans of it. Which is an awful lot of time for a
32 tupl
On Thu, 30 Sep 2004, Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
You say it's "*very* busy" is it possible there are hundreds or thousands of
tuples in there that are uncommitted or committed after this query starts?
More specifically, I bet there's a huge number of completely empty
page
Greg Stark <[EMAIL PROTECTED]> writes:
> You say it's "*very* busy" is it possible there are hundreds or thousands of
> tuples in there that are uncommitted or committed after this query starts?
More specifically, I bet there's a huge number of completely empty
pages, which would be read by a seqs
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Its a *very* busy table ... and running on a 7.4.0 database ...
I wonder how many tuples are really in this table. Almost all of the 190ms is
spent in the two sequential scans of it. Which is an awful lot of time for a
32 tuple table.
You say it'
Josh asked me to post this, since it was just "odd" ... I have
pg_autovacuum running on the table, with output looking for it looking
like:
[2004-09-30 02:29:47 PM] Performing: VACUUM ANALYZE "public"."shown"
[2004-09-30 02:35:11 PM] Performing: ANALYZE "public"."shown"
[2004-09-30 02:40:22 PM]
10 matches
Mail list logo
