Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)
Дата
Msg-id 20141002122846.GL28859@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept)  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
* Andres Freund (andres@2ndquadrant.com) wrote:
> > 1. I've decided to put pg_stat_lwlock into extension pg_stat_lwlock
> > (simply for test purposes). Is it OK, or better to implement it
> > somewhere inside pg_catalog or in another extension (for example
> > pg_stat_statements)?
>
> I personally am doubtful that it makes much sense to move this into an
> extension. It'll likely be tightly enough interlinked to backend code
> that I don't see the point. But I'd not be surprised if others feel
> differently.

I agree that this doesn't make sense as an extension.

> I generally don't think you'll get interesting data without a fair bit
> of additional work.

I'm not sure about this..

> The first problem that comes to my mind about collecting enough data is
> that we have a very large number of lwlocks (fixed_number + 2 *
> shared_buffers). One 'trivial' way of implementing this is to have a per
> backend array collecting the information, and then a shared one
> accumulating data from it over time. But I'm afraid that's not going to
> fly :(. Hm. With the above sets of stats that'd be ~50MB per backend...

I was just going to suggest exactly this- a per-backend array which then
gets pushed into a shared area periodically.  Taking up 50MB per backend
is quite a bit though. :/

> Perhaps we should somehow encode this different for individual lwlock
> tranches? It's far less problematic to collect all this information for
> all but the buffer lwlocks...

Yeah, that seems like it would at least be a good approach to begin
with.
Thanks,
    Stephen

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Replication identifiers, take 3
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pg_background (and more parallelism infrastructure patches)