Re: postgresql and process titles

On Wed, Jun 14, 2006 at 10:37:59PM +0200, Martijn van Oosterhout wrote:
> On Wed, Jun 14, 2006 at 03:21:55PM -0500, Jim C. Nasby wrote:
> > One idea would be to keep something akin to a FIFO, where the backend
> > would write records instead of updating/over-writing them, and the
> > reader process would only read records where there was no risk that they
> > were still being written. That would mean that the reader would need to
> > stay at least one record behind the backend, but that's probably
> > manageable.
>
> The problem with a FIFO is that the pointers controlling where the
> start/end are become the contention.

Even if what's being written is a single byte/word and we're taking
intentional steps to make sure that reading a pointer that's off by 1
isn't an issue? Is the issue that if CPU A writes a pointer and CPU B
immediately tries to read it that it could get old data from it's cache?

> The only thing I can think of is to have the backends only write atomic
> types and give each backend their own cache-line. The profiler would
> simply wake up every N ms and read each value, accumulating them
> somewhere.

Would everything we need fit in a cache line?

> No locking and there would be a maximum of one cache-line bounce per
> backend per N ms. I'm not sure you can get better than that under the
> situation.

What scheduler timer resolution do modern OSes use? It's likely that on
a system with more runnable processes than processors, each process will
only run for N ms anyway...

Speaking of which... doesn't the variables involved in scheduling mean
we couldn't use sampling to calculate cost in EXPLAIN ANALYZE? Or is the
assumption just that it will affect all nodes evenly?
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461