On Mon, Jan 21, 2013 at 12:22 PM, Jeff Davis <pg...@j-davis.com> wrote:

>
> On Mon, 2013-01-21 at 11:27 +0530, Pavan Deolasee wrote:
> >  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.
>
> What additional contention? How do you know it's there?
>
>
At the minimum your patch will need to have one additional buffer pinned
for every K < 8192 * 8 heap pages. For most cases, the value of K will be
large enough to ignore the overhead, but for small values of K, I'm not
sure if we can say that with confidence. Of course, for very small tables
the real contention might be somewhere else and so this change may not show
up anything on the benchmarks. Doesn't your own tests for 33 page tables
confirm that there is indeed contention for this case ? I agree its not
huge, but I don't know if there are workloads where it will matter.


> I understand that my patch is probably not going in,


Sorry about that. I know how that feels. But we need some more reasons to
justify this change, especially because the performance numbers themselves
are not showing any signs either way. One could have argued that this saves
us a valuable page level bit, but with pg_upgrade etc it has become hard to
re-utilize page level bits for other purposes and we don't yet have a
pressing need for more bits.

Thanks,
Pavan

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

Reply via email to