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.
Re: Freeze avoidance of very large table. Re: Freeze avoidance of very large table. |
| Список | pgsql-hackers |
On 7 July 2015 at 18:45, Sawada Masahiko <sawada.mshk@gmail.com> wrote:
--
I understood.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.
>
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
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: