Re: Freeze avoidance of very large table.

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: Freeze avoidance of very large table.
Дата
Msg-id CAD21AoA73jervw5P0wsRF8eaMS+Kek4db-p5OGHxfn6D4xQMWA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Freeze avoidance of very large table.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: Freeze avoidance of very large table.  (Robert Haas <robertmhaas@gmail.com>)
Re: Freeze avoidance of very large table.  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Sat, Mar 5, 2016 at 11:25 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> On Sat, Mar 5, 2016 at 1:25 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Mar 2, 2016 at 6:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>>>> On 3/2/16 4:21 PM, Peter Geoghegan wrote:
>>>>> I think you should commit this. The chances of anyone other than you
>>>>> and Masahiko recalling that you developed this tool in 3 years is
>>>>> essentially nil. I think that the cost of committing a developer-level
>>>>> debugging tool like this is very low. Modules like pg_freespacemap
>>>>> currently already have no chance of being of use to ordinary users.
>>>>> All you need to do is restrict the functions to throw an error when
>>>>> called by non-superusers, out of caution.
>>>>>
>>>>> It's a problem that modules like pg_stat_statements and
>>>>> pg_freespacemap are currently lumped together in the documentation,
>>>>> but we all know that.
>>>
>>>> +1.
>>>
>>> Would it make any sense to stick it under src/test/modules/ instead of
>>> contrib/ ?  That would help make it clear that it's a debugging tool
>>> and not something we expect end users to use.
>>
>> I actually think end-users might well want to use it.  Also, I created
>> it by hacking up pg_freespacemap, so it may make sense to have it in
>> the same place.
>> I would also be tempted to add an additional C functions that scan the
>> entire visibility map and return counts of the total number of bits of
>> each type that are set, and similarly for the page level bits.
>> Presumably that would be much faster than
>
> +1.
>
>>
>> I am also tempted to change the API to be a bit more friendly,
>> although I am not sure exactly how.  This was a quick and dirty hack
>> so that I could test, but the hardest thing about making it not a
>> quick and dirty hack is probably deciding on a good UI.
>>
>
> Does it mean visibility map API in visibilitymap.c?
>

Attached latest version optimisation patch.
I'm still consider regarding pg_upgrade regression test code, so I
will submit that patch later.

Regards,

--
Masahiko Sawada

Вложения

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: checkpointer continuous flushing - V16
Следующее
От: Andres Freund
Дата:
Сообщение: Re: checkpointer continuous flushing - V16