Re: bg worker: patch 1 of 6 - permanent process

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Markus Wanner <markus(at)bluegap(dot)ch>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bg worker: patch 1 of 6 - permanent process
Date: 2010-08-30 14:52:37
Message-ID: 25091.1283179957@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Markus Wanner <markus(at)bluegap(dot)ch> writes:
> AFAICT we currently have three fixed size blocks to manage shared
> buffers: the buffer blocks themselves, the buffer descriptors, the
> strategy status (for the freelist) and the buffer lookup table.

> It's not obvious to me how these data structures should perform better
> than a dynamically allocated layout.

Let me just point out that awhile back we got a *measurable* performance
boost by eliminating a single indirect fetch from the buffer addressing
code path. We used to have an array of pointers pointing to the actual
buffers, and we removed that in favor of assuming the buffers were
laid out in a contiguous array, so that the address of buffer N could be
computed with a shift-and-add, eliminating the pointer fetch. I forget
exactly what the numbers were, but it was significant enough to make us
change it.

So I don't have any faith in untested assertions that we can convert
these data structures to use dynamic allocation with no penalty.
It's very difficult to see how you'd do that without introducing a
new layer of indirection, and our experience shows that that layer
will cost you.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message subham 2010-08-30 15:12:10 Needs Suggestion
Previous Message Kevin Grittner 2010-08-30 14:32:14 Assertion failure on HEAD (or at least git copy of it)