On 04/25/2011 05:45 PM, Andres Freund wrote:
The profile I used in this case was:
pgbench -h /tmp/ -p5433 -s 30 pgbench -S -T 20
I'd suggest collecting data from running this with "-M prepared" at some
point too, so that you can get a basic idea which of these allocations
are avoided whe
On Tuesday, April 26, 2011 03:21:05 PM Radosław Smogura wrote:
> On Tue, 26 Apr 2011 14:25:10 +0200, Andres Freund wrote:
> > On Tuesday, April 26, 2011 01:59:45 PM Radosław Smogura wrote:
> >> I didn't followed this topic carefully, so sorry If I wrote
> >>
> >> something
> >>
> >> that was w
On Tue, 26 Apr 2011 14:25:10 +0200, Andres Freund wrote:
On Tuesday, April 26, 2011 01:59:45 PM Radosław Smogura wrote:
I didn't followed this topic carefully, so sorry If I wrote
something
that was written, but I thought about following approach at least
for
message sending, etc.:
1. Whe
On Tuesday, April 26, 2011 01:59:45 PM Radosław Smogura wrote:
> I didn't followed this topic carefully, so sorry If I wrote something
> that was written, but I thought about following approach at least for
> message sending, etc.:
>
> 1. When initializing MemoryContext (pool) give one paramet
I didn't followed this topic carefully, so sorry If I wrote something
that was written, but I thought about following approach at least for
message sending, etc.:
1. When initializing MemoryContext (pool) give one parameter that will
be stack size. Stack is addition to normal operations.
2. Op
On Tuesday, April 26, 2011 02:22:34 AM Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Apr 25, 2011 at 5:45 PM, Andres Freund wrote:
> >> [ lots of awesome test results ]
> >
> > Very interesting work. I think it's interesting that there is so much
> > allocation happening inside MessageConte
On Tuesday, April 26, 2011 01:24:20 AM Robert Haas wrote:
> On Mon, Apr 25, 2011 at 5:45 PM, Andres Freund wrote:
> > [ lots of awesome test results ]
>
> Very interesting work. I think it's interesting that there is so much
> allocation happening inside MessageContext; I barely knew that
> exis
Robert Haas writes:
> On Mon, Apr 25, 2011 at 5:45 PM, Andres Freund wrote:
>> [ lots of awesome test results ]
> Very interesting work. I think it's interesting that there is so much
> allocation happening inside MessageContext; I barely knew that
> existed, let alone that it was a hotspot for
On Tuesday, April 26, 2011 01:39:37 AM Tom Lane wrote:
> Andres Freund writes:
> > So after all this my question basically is: How important do we think the
> > mctx.c abstraction is?
>
> I think it's pretty important. As a specific example, a new context
> type in which pfree() is a no-op would
Andres Freund writes:
> So after all this my question basically is: How important do we think the
> mctx.c abstraction is?
I think it's pretty important. As a specific example, a new context
type in which pfree() is a no-op would be fine with me. A new context
type in which pfree() dumps core w
On Mon, Apr 25, 2011 at 5:45 PM, Andres Freund wrote:
> [ lots of awesome test results ]
Very interesting work. I think it's interesting that there is so much
allocation happening inside MessageContext; I barely knew that
existed, let alone that it was a hotspot for memory allocation. I
think i
Hi,
In the thread
http://archives.postgresql.org/message-id/4da69d60.4000...@2ndquadrant.com /
"Single client performance on trivial SELECTs" I wondered whether it might be
possible to increase the performance of the current allocator by using some
slab allocator like concept.
While avoiding doi
12 matches
Mail list logo
