Re: log chunking broken with large queries under load

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: log chunking broken with large queries under load
Date: 2012-04-04 16:50:16
Message-ID: 4F7C7BC8.8010601@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 04/04/2012 12:13 PM, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
>> On 04/02/2012 01:03 PM, Tom Lane wrote:
>>> When I said "list", I meant a "List *". No fixed size.
>> Ok, like this?
> I think this could use a bit of editorialization (I don't think the
> "stripe" terminology is still applicable, in particular), but the
> general idea seems OK.
>
> Does anyone feel that it's a bad idea that list entries are never
> reclaimed? In the worst case a transient load peak could result in
> a long list that permanently adds search overhead. Not sure if it's
> worth the extra complexity to delete a list cell that's no longer
> needed, rather than leaving it present and empty.

Me either. The logic could possibly be something simple when we free a
node like "while the list tail is an available node prune the tail". But
as you say, it might not be worth it.

>
>> Do we consider this a bug fix, to be backpatched?
> Yes, definitely.
>
> I think I'd like to have a go at coding it the other way (with
> release of list entries), just to see if that comes out cleaner
> or uglier than this way. If you don't mind I'll pick this up
> and commit whichever way turns out better.
>
>

Go for it.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2012-04-04 17:11:29 Re: patch: improve SLRU replacement algorithm
Previous Message Tom Lane 2012-04-04 16:47:09 Re: invalid search_path complaints