Re: Removing PD_ALL_VISIBLE - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: Removing PD_ALL_VISIBLE
Date
Msg-id CABOikdP-k=H=C_JE_pO=dQCvb7QDxYfFeQSzGDOyuBTCu3c8bg@mail.gmail.com
Whole thread Raw
In response to Re: Removing PD_ALL_VISIBLE  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Removing PD_ALL_VISIBLE
List 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 by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Further pg_upgrade analysis for many tables
Next
From: Pavan Deolasee
Date:
Subject: Re: pg_dump transaction's read-only mode