Re: pgsql: Compute XID horizon for page level index vacuum on primary.

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: pgsql: Compute XID horizon for page level index vacuum on primary.
Дата
Msg-id CA+hUKGJ1NA0zoB5PTaxLg_FM1S0FVkdbFxjGiYa+syp48g9=mQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pgsql: Compute XID horizon for page level index vacuum on primary.  (Andres Freund <andres@anarazel.de>)
Ответы Re: pgsql: Compute XID horizon for page level index vacuum on primary.  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-committers
On Fri, Mar 29, 2019 at 4:27 AM Andres Freund <andres@anarazel.de> wrote:
> On March 28, 2019 11:24:46 AM EDT, Peter Geoghegan <pg@bowt.ie> wrote:
> >On Thu, Mar 28, 2019 at 5:28 AM Andres Freund <andres@anarazel.de>
> >wrote:
> >> Hm, good catch.  I don't like this fix very much (even if it were
> >> commented), but I don't have a great idea right now.
> >
> >That was just a POC, to verify the problem. Not a proposal.
>
> I'm mildly inclined to push a commented version of this. And add a open items entry.  Alternatively I'm thinking of
justbut taking the tablespace setting into account.
 

I didn't understand that last sentence.

Here's an attempt to write a suitable comment for the quick fix.  And
I suppose effective_io_concurrency is a reasonable default.

It's pretty hard to think of a good way to get your hands on the real
value safely from here.  I wondered if there was a way to narrow this
to just GLOBALTABLESPACE_OID since that's where pg_tablespace lives,
but that doesn't work, we access other catalog too in that path.

Hmm, it seems a bit odd that 0 is supposed to mean "disable issuance
of asynchronous I/O requests" according to config.sgml, but here 0
will prefetch 10 buffers.

-- 
Thomas Munro
https://enterprisedb.com

Вложения

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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: pgsql: Generated columns
Следующее
От: Peter Eisentraut
Дата:
Сообщение: pgsql: doc: Fix typo