Re: Removing PD_ALL_VISIBLE

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: Removing PD_ALL_VISIBLE
Дата
Msg-id CABOikdP-k=H=C_JE_pO=dQCvb7QDxYfFeQSzGDOyuBTCu3c8bg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Removing PD_ALL_VISIBLE  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Removing PD_ALL_VISIBLE  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
On Mon, Jan 21, 2013 at 8:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> 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.
>
> Yeah, I'm having the same problem.  Despite Jeff's test results, I can't
> help thinking that lack of PD_ALL_VISIBLE *will* hurt us under some
> workloads, and it's not obvious to me what benefit we get from dropping
> it.

I tend to agree. When I looked at the patch, I thought since its
removing a WAL record (and associated redo logic), it has some
additional value. But that was kind of broken (sorry, I haven't looked
at the latest patch if Jeff fixed it without requiring to reinstate
the WAL logging). I also thought that bug invalidates the performance
numbers reported. Of course, there is an argument that this patch will
simplify the code, but I'm not sure if its enough to justify the
additional contention which may or may not show up in the benchmarks
we are running, but we know its there.

Thanks,
Pavan

-- 
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee



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

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: Further pg_upgrade analysis for many tables
Следующее
От: Pavan Deolasee
Дата:
Сообщение: Re: pg_dump transaction's read-only mode