Re: [HACKERS] CREATE INDEX speeds up query on 31 row table ...

2004-10-01 Thread Marc G. Fournier
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 ...

[HACKERS] CREATE INDEX speeds up query on 31 row table ...

2004-09-30 Thread Marc G. Fournier
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]

Re: [HACKERS] CREATE INDEX speeds up query on 31 row table ...

2004-09-30 Thread Greg Stark
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's

Re: [HACKERS] CREATE INDEX speeds up query on 31 row table ...

2004-09-30 Thread Tom Lane
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 seqscan

Re: [HACKERS] CREATE INDEX speeds up query on 31 row table ...

2004-09-30 Thread Marc G. Fournier
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 pages,

Re: [HACKERS] CREATE INDEX speeds up query on 31 row table ...

2004-09-30 Thread Matthew T. O'Connor
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 tuple

Re: [HACKERS] CREATE INDEX speeds up query on 31 row table ...

2004-09-30 Thread Matthew T. O'Connor
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 would

Re: [HACKERS] CREATE INDEX speeds up query on 31 row table ...

2004-09-30 Thread Marc G. Fournier
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

Re: [HACKERS] CREATE INDEX speeds up query on 31 row table ...

2004-09-30 Thread Matthew T. O'Connor
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