Re: [HACKERS] Reporting xmin from VACUUMs

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Reporting xmin from VACUUMs
Дата
Msg-id CA+TgmoaUSKfNDruXfie+aNre3tLq-wMiizz86N0nvUie7q3A-Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Reporting xmin from VACUUMs  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: [HACKERS] Reporting xmin from VACUUMs  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
On Sat, Feb 18, 2017 at 12:30 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> What?
>
> There's a bunch of information reported by vacuum logging but not in
> pg_stat*, such as all-visible/frozen skipping, unable to get cleanup lock,
> last freeze scan, times autovac has been interrupted. There's been
> resistance in the past to further bloating the existing stats files, but if
> we allowed more than one stats file per database that bloat would be less of
> a concern (since vacuum stats will see far less update traffic than the main
> relation stats).

This is the kind of information that you really want to see once per
autovac, though, not just the most recent autovac or some kind of
cumulative total.  Knowing that I've done 301 index scans in my last
300 vacuums is not nearly as useful as knowing which autovacuum did 2
index scans and what exactly was going on with that vacuum.  So I'm
not sure including this sort of thing in the stats files would be very
useful, or at least you'd want to think carefully about how to do it.

As far as bloating the stats file is concerned, the big problem there
is that our current design for the stats file requires rewriting the
entire thing any time we want to update even a single byte of data.
We could fix that by splitting up the files more so that they are
smaller and faster to rewrite, but we could also fix it by coming up
with a way of rewriting just one part of a file instead of the whole
thing, or we could think about storing it in DSM so that you don't
have to rewrite anything at all.  I think that last option is worth
some serious study now that we have DSA, but it's currently not very
high on my personal priority list.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От:
Дата:
Сообщение: [HACKERS] Adding new output parameter of pg_stat_statements to identify operation of the query.
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Replication vs. float timestamps is a disaster