| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Kris Kennaway <kris(at)obsecurity(dot)org>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: postgresql and process titles |
| Date: | 2006-06-14 19:51:28 |
| Message-ID: | 2989.1150314688@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> This sounds good until you think about locking. It'd be quite
>> impractical to implement anything as fine-grained as EXPLAIN ANALYZE
>> this way, because of the overhead involved in taking and releasing
>> spinlocks.
> I'm not entirely convinced. The only other process that would be looking at
> the information would be the statistics accumulator which would only be waking
> up every 100ms or so. There would be no contention with other backends
> reporting their info.
The numbers I've been looking at lately say that heavy lock traffic is
expensive, particularly on SMP machines, even with zero contention.
Seems the cache coherency protocol costs a lot even when it's not doing
anything...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2006-06-14 20:12:59 | Re: Alternative variable length structure |
| Previous Message | Bruce Momjian | 2006-06-14 19:33:19 | Re: 64-bit API for large objects |