At 1:57 PM -0500 2/24/08, Tom Lane wrote:
Joel Stevenson <[EMAIL PROTECTED]> writes:
This sounds a bit like pg_listener has gotten bloated. Try a "VACUUM
VERBOSE pg_listener" (as superuser) and see what it says.
At the moment (server is inactive):
pcdb=# VACUUM VERBOSE pg_listener;
I
On Sun, Feb 24, 2008 at 6:05 PM, Sean Leach <[EMAIL PROTECTED]> wrote:
> On Feb 24, 2008, at 4:03 PM, Scott Marlowe wrote:
>
> >
> > What version pgsql is this? If it's pre 8.0 it might be worth looking
> > into migrating for performance and maintenance reasons.
>
> It's the latest 8.3.0 rel
On Feb 24, 2008, at 4:03 PM, Scott Marlowe wrote:
The fact that your indexes are bloated but your table is not makes me
wonder if you're not running a really old version of pgsql that had
problems with monotonically increasing indexes bloating over time and
requiring reindexing.
That problem h
The fact that your indexes are bloated but your table is not makes me
wonder if you're not running a really old version of pgsql that had
problems with monotonically increasing indexes bloating over time and
requiring reindexing.
That problem has been (for the most part) solved by some hacking Tom
On Feb 24, 2008, at 1:18 PM, Stephen Denne wrote:
If you always get around a third of the rows in your table written
in the last day, you've got to be deleting about a third of the rows
in your table every day too. You might have a huge number of dead
rows in your table, slowing down the se
Tom Lane wrote
> Sean Leach <[EMAIL PROTECTED]> writes:
> > Now - here is prod:
>
> > db=> select count(1) from u_counts;
> >count
> > -
> > 3292215
> > (1 row)
>
>
> > -> Seq Scan on u_counts c (cost=0.00..444744.45
> > rows=1106691 width=4) (actual time=1429.996..78
On Feb 24, 2008, at 11:10 AM, Tom Lane wrote:
Sean Leach <[EMAIL PROTECTED]> writes:
Now - here is prod:
db=> select count(1) from u_counts;
count
-
3292215
(1 row)
-> Seq Scan on u_counts c (cost=0.00..444744.45
rows=1106691 width=4) (actual time=1429.996..7893.17
Sean Leach <[EMAIL PROTECTED]> writes:
> Now - here is prod:
> db=> select count(1) from u_counts;
>count
> -
> 3292215
> (1 row)
> -> Seq Scan on u_counts c (cost=0.00..444744.45
> rows=1106691 width=4) (actual time=1429.996..7893.178 rows=1036015
> loops=1)
>
Joel Stevenson <[EMAIL PROTECTED]> writes:
>> This sounds a bit like pg_listener has gotten bloated. Try a "VACUUM
>> VERBOSE pg_listener" (as superuser) and see what it says.
> At the moment (server is inactive):
> pcdb=# VACUUM VERBOSE pg_listener;
> INFO: vacuuming "pg_catalog.pg_listener"
>
Nope, seems like that would make sense but dev is 10 mill, prod is 3
million. Also including random_page_cost below. Thanks for any help.
Here is dev:
db=> analyze u_counts;
ANALYZE
Time: 15775.161 ms
db=> select count(1) from u_counts;
count
--
10972078
(1 row)
db=> show rand
Sean Leach <[EMAIL PROTECTED]> writes:
> I have a table, that in production, currently has a little over 3
> million records in production. In development, the same table has
> about 10 million records (we have cleaned production a few weeks
> ago).
You mean the other way around, to judge b
I have a table, that in production, currently has a little over 3
million records in production. In development, the same table has
about 10 million records (we have cleaned production a few weeks
ago). One of my queries joins this table with another, and in
development, the particular co
12 matches
Mail list logo
