Tom Lane píše v pá 13. 11. 2009 v 16:06 -0500:
> Zdenek Kotala <zdenek.kot...@sun.com> writes:
> > Attached patch contains new dtrace probes for memory management.
>
> This is a bad idea and I want to reject it outright. No ordinary user
> is really going to care about those details, and palloc is a
> sufficiently hot hot-spot that even the allegedly negligible overhead
> of an inactive dtrace probe is going to cost us.
I don't think that impact is too big here. User space DTrace probes are
implemented like function call. When probe is inactive call is replaced
by nop. Only what stay in code is arguments preparations.
there is asm code 32bit intel from palloc:
MemoryContextAlloc+0xae: pushl $0x0
MemoryContextAlloc+0xb0: pushl -0x8(%ebx)
MemoryContextAlloc+0xb3: pushl 0xc(%ebp)
MemoryContextAlloc+0xb6: movl 0x8(%ebp),%eax
MemoryContextAlloc+0xb9: pushl %eax
MemoryContextAlloc+0xba: pushl 0x14(%eax)
MemoryContextAlloc+0xbd: nop
MemoryContextAlloc+0xbe: nop
MemoryContextAlloc+0xbf: nop
MemoryContextAlloc+0xc0: nop
MemoryContextAlloc+0xc1: nop
MemoryContextAlloc+0xc2: addl $0x20,%esp
You can see is that overhead depends on number of argument. I used five
arguments now but two can be enough. Only dtrace script will be
complicated in some cases after that.
By my opinion if you compare whole palloc code path, Dtrace probes
overhead is minimal.
Zdenek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
