Re: Freeze avoidance of very large table.

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: Freeze avoidance of very large table.
Дата
Msg-id CAD21AoCY2aGqQ=0UA-vk7y9RO0oyH=N=0yiSW4PnPPUP7jZpYQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Freeze avoidance of very large table.  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Freeze avoidance of very large table.  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Aug 10, 2015 at 11:05 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Mon, Aug 10, 2015 at 12:39 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Thu, Aug 6, 2015 at 11:33 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>>> They also provide a level of control over what is and isn't installed in a
>>> cluster. Personally, I'd prefer that most users not even be aware of the
>>> existence of things like pageinspect.
>>
>> +1.
>>
>> [...]
>>
>> Extensions are a useful packaging mechanism for functionality that is
>> useful but not required, and debugging facilities are definitely very
>> useful but should not be required.
>
> +1.

Sorry to be come discussion late.

I have encountered the much cases where pg_stat_statement,
pgstattuples are required in production, so I basically agree with
moving such extension into core.
But IMO, the diagnostic tools for visibility map, heap (pageinspect)
and so on, are a kind of debugging tool.

Attached latest v11 patches, which is separated into 2 patches: frozen
bit patch and diagnostic function patch.
Moving diagnostic function into core is still under the discussion,
but this patch puts such function into core because the diagnostic
function for visibility map needs to be in core to execute regression
test at least.

Regards,

--
Masahiko Sawada

Вложения

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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: Declarative partitioning
Следующее
От: Peter Eisentraut
Дата:
Сообщение: allowing wal_level change at run time