Re: log chunking broken with large queries under load

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: log chunking broken with large queries under load
Дата
Msg-id 4F7C7BC8.8010601@dunslane.net
обсуждение исходный текст
Ответ на Re: log chunking broken with large queries under load  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: log chunking broken with large queries under load  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

On 04/04/2012 12:13 PM, Tom Lane wrote:
> Andrew Dunstan<andrew@dunslane.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: invalid search_path complaints
Следующее
От: Greg Stark
Дата:
Сообщение: Re: patch: improve SLRU replacement algorithm