Re: Removing PD_ALL_VISIBLE

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Removing PD_ALL_VISIBLE
Дата
Msg-id CA+TgmoZVX9tQ9pGOKupwsqLUAswjKydv8APEhr-edGDxppjunw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Removing PD_ALL_VISIBLE  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Removing PD_ALL_VISIBLE  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Jan 18, 2013 at 3:31 AM, Jeff Davis <pgsql@j-davis.com> wrote:
> So, I attached a new version of the patch that doesn't look at the VM
> for tables with fewer than 32 pages. That's the only change.

That certainly seems worthwhile, but I still don't want to get rid of
this code.  I'm just not seeing a reason why that's something that
desperately needs to be done.  I don't think this is a barrier to
anything else we want to do, and it might well be that the situations
where this patch would hurt us are currently masked by other
bottlenecks, but won't be always.  Right now, the vast majority of
heap updates don't need to pin the visibility map page; with this
change, all of them do.  Now, I accept that your test results show
that that doesn't matter, but how can that not be an artifact of some
kind?  Can we really credit that accessing two pages costs no more
than accessing one?  To what countervailing factor could we plausibly
attribute that?

Now, even if it costs more in some narrow sense, the difference might
not be enough to matter.  But without some big gain on the other side,
why tinker with it?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]