I wrote:
> Andres Freund writes:
>> On 2017-12-12 14:50:37 -0500, Robert Haas wrote:
>>> Another idea I have is that perhaps we could arrange to reuse contexts
>>> instead of destroying them and recreating them.
>> I'm a bit doubtful that's going to help, maintaining that list isn't
>> going to b
Andres Freund writes:
> On 2017-12-12 14:50:37 -0500, Robert Haas wrote:
>> It strikes me that a way to optimize these cases even more would be to
>> postpone creating the context until it's actually needed. That might
>> not always be a reasonable plan -- in particular, it occurs to me to
>> thi
On 2017-12-12 14:50:37 -0500, Robert Haas wrote:
> On Tue, Dec 12, 2017 at 2:30 PM, Tom Lane wrote:
> > 379 CurTransactionContext was never used
> > 24 CurTransactionContext was used
> > 66978 ExprContext was never used
> > 17364 ExprContext was used
> > 11139 SPI Exec was never use
On Tue, Dec 12, 2017 at 2:30 PM, Tom Lane wrote:
> 379 CurTransactionContext was never used
> 24 CurTransactionContext was used
> 66978 ExprContext was never used
> 17364 ExprContext was used
> 11139 SPI Exec was never used
>2421 SPI Exec was used
> 38386 ginPlaceToPage tempor
I wrote:
> I've not done any benchmarking on this yet, just confirmed that it
> compiles and passes check-world.
So once I'd done some benchmarking, I was a bit disappointed: I could
not measure any difference anymore in "pgbench -S", and poking into
other scenarios found cases that were actually
On 11 December 2017 at 17:38, Tom Lane wrote:
> Simon Riggs writes:
>> On 11 December 2017 at 16:27, Tom Lane wrote:
>>> For a *very* large majority of the callers of AllocSetContextCreate,
>>> the context name is a simple C string constant, so we could just store
>>> the pointer to it and save
Robert Haas writes:
> On Mon, Dec 11, 2017 at 12:36 PM, Tom Lane wrote:
>> [ thinks... ] If we wanted to go that way, one thing we could do to
>> help extension authors (and ourselves) is to define the proposed
>> AllocSetContextCreate macro to include
>>
>> StaticAssertExpr(__builtin_cons
On 2017-12-11 13:09:42 -0500, Tom Lane wrote:
> Tomas Vondra writes:
> > On 12/10/2017 04:42 PM, Tom Lane wrote:
> >> Peter Geoghegan writes:
> >>> On Sat, Dec 9, 2017 at 5:53 PM, Tom Lane wrote:
> Overall I'm seeing about a 5% improvement in a "pgbench -S" scenario,
> although that nu
Tomas Vondra writes:
> On 12/10/2017 04:42 PM, Tom Lane wrote:
>> Peter Geoghegan writes:
>>> On Sat, Dec 9, 2017 at 5:53 PM, Tom Lane wrote:
Overall I'm seeing about a 5% improvement in a "pgbench -S" scenario,
although that number is a bit shaky since the run-to-run variation
is
On 12/10/2017 04:42 PM, Tom Lane wrote:
> Peter Geoghegan writes:
>> On Sat, Dec 9, 2017 at 5:53 PM, Tom Lane wrote:
>>> Overall I'm seeing about a 5% improvement in a "pgbench -S" scenario,
>>> although that number is a bit shaky since the run-to-run variation
>>> is a few percent anyway.
>
>>
On Mon, Dec 11, 2017 at 12:36 PM, Tom Lane wrote:
> [ thinks... ] If we wanted to go that way, one thing we could do to
> help extension authors (and ourselves) is to define the proposed
> AllocSetContextCreate macro to include
>
> StaticAssertExpr(__builtin_constant_p(name))
>
> on compi
Robert Haas writes:
> On Mon, Dec 11, 2017 at 11:59 AM, Tom Lane wrote:
>> Tomas Vondra writes:
>>> On 12/11/2017 05:27 PM, Tom Lane wrote:
However, unless we want to run around and touch all the ~ 150 calls
with constant arguments, we'd have to set things up so that the default
Simon Riggs writes:
> On 11 December 2017 at 16:27, Tom Lane wrote:
>> For a *very* large majority of the callers of AllocSetContextCreate,
>> the context name is a simple C string constant, so we could just store
>> the pointer to it and save the space and cycles required to copy it.
> Why have
On 12/11/2017 06:22 PM, Robert Haas wrote:
> On Mon, Dec 11, 2017 at 11:59 AM, Tom Lane wrote:
>> Tomas Vondra writes:
>>> On 12/11/2017 05:27 PM, Tom Lane wrote:
However, unless we want to run around and touch all the ~ 150 calls
with constant arguments, we'd have to set things up so t
Robert Haas writes:
> On Mon, Dec 11, 2017 at 11:59 AM, Tom Lane wrote:
>> Tomas Vondra writes:
>>> On 12/11/2017 05:27 PM, Tom Lane wrote:
However, unless we want to run around and touch all the ~ 150 calls
with constant arguments, we'd have to set things up so that the default
b
On 11 December 2017 at 16:27, Tom Lane wrote:
> For a *very* large majority of the callers of AllocSetContextCreate,
> the context name is a simple C string constant, so we could just store
> the pointer to it and save the space and cycles required to copy it.
Why have the string at all in that
On Mon, Dec 11, 2017 at 11:59 AM, Tom Lane wrote:
> Tomas Vondra writes:
>> On 12/11/2017 05:27 PM, Tom Lane wrote:
>>> However, unless we want to run around and touch all the ~ 150 calls
>>> with constant arguments, we'd have to set things up so that the default
>>> behavior for AllocSetContextC
Tomas Vondra writes:
> On 12/11/2017 05:27 PM, Tom Lane wrote:
>> However, unless we want to run around and touch all the ~ 150 calls
>> with constant arguments, we'd have to set things up so that the default
>> behavior for AllocSetContextCreate is to not copy. This risks breaking
>> callers in
On 12/11/2017 05:27 PM, Tom Lane wrote:
> I wrote:
>> While fooling around with a different problem, I got annoyed at how slow
>> MemoryContext creation and deletion is.
>
> Looking at this some more, there's another micro-optimization we could
> make, which is to try to get rid of the strlen+st
I wrote:
> While fooling around with a different problem, I got annoyed at how slow
> MemoryContext creation and deletion is.
Looking at this some more, there's another micro-optimization we could
make, which is to try to get rid of the strlen+strcpy operations needed
for the context name. (And y
Peter Geoghegan writes:
> On Sat, Dec 9, 2017 at 5:53 PM, Tom Lane wrote:
>> Overall I'm seeing about a 5% improvement in a "pgbench -S" scenario,
>> although that number is a bit shaky since the run-to-run variation
>> is a few percent anyway.
> Is that with "-M prepared", too?
No, I didn't us
On Sat, Dec 9, 2017 at 5:53 PM, Tom Lane wrote:
> Overall I'm seeing about a 5% improvement in a "pgbench -S" scenario,
> although that number is a bit shaky since the run-to-run variation
> is a few percent anyway.
Is that with "-M prepared", too?
--
Peter Geoghegan
While fooling around with a different problem, I got annoyed at how slow
MemoryContext creation and deletion is. A big chunk of that seems to be
the palloc/pfree cycle needed to allocate the context header block in
TopMemoryContext. After thinking about it for a bit, I decided that
it'd be smarte
23 matches
Mail list logo
