Bill Moran wrote:
>
> My apologies, I should have asked for the output of VACUUM VERBOSE on
> the problem table in conjunction with these settings. (make sure you
> do VACUUM VERBOSE when the table is exhibiting the speed problem)
>
INFO: vacuuming "public.session_allocation_info"
INFO: sc
Andy Colson-2 wrote:
>
> Can you post an explain analyze'es'es for (1) when its quick and (2)
> when its slow?
>
Here are results:
1. Upon startup:
QUERY
PLAN
Scott Marlowe-2 wrote:
>
> Just wondering, what version of pgsql are you running? I noticed a
> lot less degradation from heavily updated tables when I went to 8.3
> and set the fill % for tables / indexes to 90% or so. If you're
> running an older version, the upgrade to 8.3 may well be wort
Bill Moran wrote:
>
> The OP did mention that he's using autovac, which will take care of
> both vacuum and analyze for him. However, he didn't provide his
> autovac config, and it happens at times that the defaults are not
> aggressive enough to keep a table well-maintained.
>
Here are my a
Brian Modra-2 wrote:
>
> When did you last do an analyse and re-create indexes?
> Is the table UPDATEd to or DELETEd from, or just INSERTed ?
> Is your DB auto vacuuming?
>
My DB is auto-vacuuming all the time. The specific table I'm talking about
gets vacuumed at least every 2 hours (usually
I have a table with 5 million rows. 10 inserts and deletes are performed on
this table every second.
The table has indexes on the columns I use to query it, and the query is
returning about a 1000 rows. Initially the query takes a very short time
(order of miliseconds), after a few hours it takes
Tom Lane-2 wrote:
>
> tomrevam writes:
> It might help to increase wal_buffers.
>
Hi,
I increased the wal_buffers to 2 MB. Initially this improved the performance
very much, but after 4 days of continuous operation the system is back to
very long inserts and updates (at least
Alvaro Herrera-7 wrote:
>
> tomrevam wrote:
>
> This is why Tom was suggesting you to increase wal_buffers. Did
> you try that?
>
>
Increasing the wal_buffers improved the performance. Is there a limit on how
big I can raise them? Is there anything that would w
Alvaro Herrera-7 wrote:
>
> This is why Tom was suggesting you to increase wal_buffers. Did
> you try that?
>
Thanks for the explanation. I will try increasing the wal_buffers.
Unfortunately this is on a system I can't restart for the next few days.
Tomer
--
View this message in context:
Greg Smith-12 wrote:
>
> On Thu, 23 Jul 2009, tomrevam wrote:
>
>> bgwriter_delay = 20ms # 10-1ms between rounds
>> bgwriter_lru_maxpages = 1000# 0-1000 max buffers
>> written/round
>> bgwriter_lru_multiplier = 5.0
Tom Lane-2 wrote:
>
>
> What sort of disk hardware have you got? It sounds overstressed.
>
> It might help to increase wal_buffers.
>
>
The disk is a SATA drive and it will be replaced in future projects with a
better drive. However, I still don't understand why there is any halt in the
c
Hi,
I set synchronous_commit to off and expected trivial inserts (single row,
6-8 columns) to always return quickly. However, I see that during
checkpoints they sometimes take over a second. I tried setting the
full_page_write to off, but this didn't seem to have an effect.
The version I'm using
Dan Armbrust wrote:
>
> All of my testing to date has been done with synchronous_commit=off
>
> I just tried setting full_page_writes=off - and like magic, the entire
> hiccup went away.
>
Why is the full_page_write happening before the commit returns when
synchronous_commit is set to off? I
13 matches
Mail list logo
