Re: Freeze avoidance of very large table.

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Freeze avoidance of very large table.
Дата
Msg-id CANP8+jKLc9Fo_+v6v2sQiU74hhrvGrukq-hoaVSX+-y+AzwawA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Freeze avoidance of very large table.  (Sawada Masahiko <sawada.mshk@gmail.com>)
Ответы Re: Freeze avoidance of very large table.  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: Freeze avoidance of very large table.  (Sawada Masahiko <sawada.mshk@gmail.com>)
Re: Freeze avoidance of very large table.  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On 7 July 2015 at 18:45, Sawada Masahiko <sawada.mshk@gmail.com> wrote:
On Wed, Jul 8, 2015 at 12:37 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2015-07-07 16:25:13 +0100, Simon Riggs wrote:
>> I don't think pg_freespacemap is the right place.
>
> I agree that pg_freespacemap sounds like an odd location.
>
>> I'd prefer to add that as a single function into core, so we can write
>> formal tests.
>
> With the advent of src/test/modules it's not really a prerequisite for
> things to be builtin to be testable. I think there's fair arguments for
> moving stuff like pg_stattuple, pg_freespacemap, pg_buffercache into
> core at some point, but that's probably a separate discussion.
>

I understood.
So I will place bunch of test like src/test/module/visibilitymap_test,
which contains  some tests regarding this feature,
and gather them into one patch.

Please place it in core. I see value in having a diagnostic function for general use on production systems.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Предыдущее
От: Zhaomo Yang
Дата:
Сообщение: Re: Implementation of global temporary tables?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: configure can't detect proper pthread flags