On 10/02/2012 05:24 AM, Colin Taylor wrote:
My thoughts are: surely 0-row updates dont cause this or have impact on
the vacuum. I'm still doing the same updates after all why have things
degenerated so badly?
What exactly is bloating? Have you checked? Is it the table its self?
One of its inde
Stefan --
- Original Message -
> From: Stefan Keller
> To: Ivan Voras
> Cc: pgsql-performance@postgresql.org
> Sent: Monday, October 1, 2012 5:15 PM
> Subject: Re: [PERFORM] Inserts in 'big' table slowing down the database
>
> Sorry for the delay. I had to sort out the problem (among o
Sorry for the delay. I had to sort out the problem (among other things).
It's mainly about swapping.
The table nodes contains about 2^31 entries and occupies about 80GB on
disk space plus index.
If one would store the geom values in a big array (where id is the
array index) it would only make up
Well, I've managed to track down the cause of improper plans.
Due to the data distribution n_distinct had been estimated way too low.
I've manually set it to be 195300 instead of 15500 (with stats_target=200):
select tablename,attname,null_frac,avg_width,n_distinct,correlation
from pg_stats
whe
Hi, previously I selected categorized data for update then updated counts
or inserted a new record if it was a new category of data.
select all categories
update batches of categories
or insert batches [intermingled as they hit batch size]
Problem was the select was saturating the network (pullin
> -Original Message-
> From: Thomas Kellerer [mailto:spam_ea...@gmx.net]
> Sent: Tuesday, September 25, 2012 7:24 AM
> To: pgsql-performance@postgresql.org
> Subject: Re: Postgres becoming slow, only full vacuum fixes it
>
> Kiriakos Tsourapas, 25.09.2012 13:01:
> > Thank you,
> >
> > I wi
