Re: [HACKERS] Deferring some AtStart* allocations?

2014-10-29 Thread Robert Haas
On Tue, Oct 28, 2014 at 10:16 AM, Andres Freund and...@2ndquadrant.com wrote: On 2014-10-24 11:25:23 -0400, Robert Haas wrote: On Fri, Oct 24, 2014 at 10:10 AM, Andres Freund and...@2ndquadrant.com wrote: What I was thinking was that you'd append the messages to the layer one level deeper

Re: [HACKERS] Deferring some AtStart* allocations?

2014-10-28 Thread Andres Freund
On 2014-10-24 11:25:23 -0400, Robert Haas wrote: On Fri, Oct 24, 2014 at 10:10 AM, Andres Freund and...@2ndquadrant.com wrote: What I was thinking was that you'd append the messages to the layer one level deeper than the parent. Then we'd missed the invalidations when rolling back the

Re: [HACKERS] Deferring some AtStart* allocations?

2014-10-24 Thread Andres Freund
On 2014-10-23 12:04:40 -0400, Robert Haas wrote: On Tue, Oct 21, 2014 at 12:00 PM, Andres Freund and...@2ndquadrant.com wrote: On 2014-10-09 15:01:19 -0400, Robert Haas wrote: /* @@ -960,18 +966,38 @@ AtEOXact_Inval(bool isCommit) ... + /* + * We create

Re: [HACKERS] Deferring some AtStart* allocations?

2014-10-24 Thread Robert Haas
On Fri, Oct 24, 2014 at 9:17 AM, Andres Freund and...@2ndquadrant.com wrote: If that subtransaction abouts, AtEOSubXact_Inval() gets called again, sees that it has messages (that it inherited from the innermost subtransaction), and takes the exact same code-path that it would have pre-patch.

Re: [HACKERS] Deferring some AtStart* allocations?

2014-10-24 Thread Andres Freund
On 2014-10-24 09:45:59 -0400, Robert Haas wrote: On Fri, Oct 24, 2014 at 9:17 AM, Andres Freund and...@2ndquadrant.com wrote: If that subtransaction abouts, AtEOSubXact_Inval() gets called again, sees that it has messages (that it inherited from the innermost subtransaction), and takes

Re: [HACKERS] Deferring some AtStart* allocations?

2014-10-23 Thread Robert Haas
On Tue, Oct 21, 2014 at 12:00 PM, Andres Freund and...@2ndquadrant.com wrote: On 2014-10-09 15:01:19 -0400, Robert Haas wrote: /* @@ -960,18 +966,38 @@ AtEOXact_Inval(bool isCommit) ... + /* + * We create invalidation stack entries lazily, so the parent might +

Re: [HACKERS] Deferring some AtStart* allocations?

2014-10-21 Thread Andres Freund
On 2014-10-08 13:52:14 -0400, Robert Haas wrote: On Sun, Jun 29, 2014 at 9:12 PM, Tom Lane t...@sss.pgh.pa.us wrote: Meh. Even SELECT 1 is going to be doing *far* more pallocs than that to get through raw parsing, parse analysis, planning, and execution startup. If you can find a few

Re: [HACKERS] Deferring some AtStart* allocations?

2014-10-21 Thread Andres Freund
Hi, On 2014-10-09 15:01:19 -0400, Robert Haas wrote: /* @@ -960,18 +966,38 @@ AtEOXact_Inval(bool isCommit) ... + /* + * We create invalidation stack entries lazily, so the parent might + * not have one. Instead of creating one, moving all the data

Re: [HACKERS] Deferring some AtStart* allocations?

2014-10-16 Thread Simon Riggs
On 9 October 2014 20:01, Robert Haas robertmh...@gmail.com wrote: OK, here's an attempt at a real patch for that. I haven't perf-tested this. Patch looks good to me. Surprised we didn't do that before. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development,

Re: [HACKERS] Deferring some AtStart* allocations?

2014-10-09 Thread Andres Freund
On 2014-10-08 13:52:14 -0400, Robert Haas wrote: On Sun, Jun 29, 2014 at 9:12 PM, Tom Lane t...@sss.pgh.pa.us wrote: Meh. Even SELECT 1 is going to be doing *far* more pallocs than that to get through raw parsing, parse analysis, planning, and execution startup. If you can find a few

Re: [HACKERS] Deferring some AtStart* allocations?

2014-10-09 Thread Robert Haas
On Thu, Oct 9, 2014 at 5:34 AM, Andres Freund and...@2ndquadrant.com wrote: Interesting - in my local profile AtStart_Inval() is more pronounced than AfterTriggerBeginQuery(). I've quickly and in a ugly fashion hacked AtStart_Inval() out of readonly queries ontop of your patch. Together that

Re: [HACKERS] Deferring some AtStart* allocations?

2014-10-09 Thread Andres Freund
On 2014-10-09 08:18:18 -0400, Robert Haas wrote: On Thu, Oct 9, 2014 at 5:34 AM, Andres Freund and...@2ndquadrant.com wrote: Interesting - in my local profile AtStart_Inval() is more pronounced than AfterTriggerBeginQuery(). I've quickly and in a ugly fashion hacked AtStart_Inval() out of

Re: [HACKERS] Deferring some AtStart* allocations?

2014-10-09 Thread Robert Haas
On Thu, Oct 9, 2014 at 8:20 AM, Andres Freund and...@2ndquadrant.com wrote: On 2014-10-09 08:18:18 -0400, Robert Haas wrote: On Thu, Oct 9, 2014 at 5:34 AM, Andres Freund and...@2ndquadrant.com wrote: Interesting - in my local profile AtStart_Inval() is more pronounced than

Re: [HACKERS] Deferring some AtStart* allocations?

2014-10-09 Thread Andres Freund
On 2014-10-09 15:01:19 -0400, Robert Haas wrote: On Thu, Oct 9, 2014 at 8:20 AM, Andres Freund and...@2ndquadrant.com wrote: On 2014-10-09 08:18:18 -0400, Robert Haas wrote: On Thu, Oct 9, 2014 at 5:34 AM, Andres Freund and...@2ndquadrant.com wrote: Interesting - in my local profile

Re: [HACKERS] Deferring some AtStart* allocations?

2014-10-09 Thread Robert Haas
On Thu, Oct 9, 2014 at 3:53 PM, Andres Freund and...@2ndquadrant.com wrote: OK, here's an attempt at a real patch for that. I haven't perf-tested this. Neato. With a really trivial SELECT: before: tps = 28150.794776 (excluding connections establishing) after: tps = 29978.767703 (excluding

Re: [HACKERS] Deferring some AtStart* allocations?

2014-10-09 Thread Andres Freund
On 2014-10-09 17:02:02 -0400, Robert Haas wrote: On Thu, Oct 9, 2014 at 3:53 PM, Andres Freund and...@2ndquadrant.com wrote: OK, here's an attempt at a real patch for that. I haven't perf-tested this. Neato. With a really trivial SELECT: before: tps = 28150.794776 (excluding

Re: [HACKERS] Deferring some AtStart* allocations?

2014-10-08 Thread Amit Kapila
On Wed, Oct 8, 2014 at 11:22 PM, Robert Haas robertmh...@gmail.com wrote: On Sun, Jun 29, 2014 at 9:12 PM, Tom Lane t...@sss.pgh.pa.us wrote: Meh. Even SELECT 1 is going to be doing *far* more pallocs than that to get through raw parsing, parse analysis, planning, and execution startup.

[HACKERS] Deferring some AtStart* allocations?

2014-06-29 Thread Andres Freund
Hi, In workloads with mostly simple statements, memory allocations are the primary bottleneck. Some of the allocations are unlikely to be avoidable without major work, but others seem superflous in many scenarios. Why aren't we delaying allocations in e.g. AtStart_Inval(),

Re: [HACKERS] Deferring some AtStart* allocations?

2014-06-29 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: Why aren't we delaying allocations in e.g. AtStart_Inval(), AfterTriggerBeginXact() to when the data structures are acutally used? Aren't we? Neither of those would be doing much work certainly. regards, tom lane -- Sent

Re: [HACKERS] Deferring some AtStart* allocations?

2014-06-29 Thread Andres Freund
On 2014-06-29 19:52:23 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: Why aren't we delaying allocations in e.g. AtStart_Inval(), AfterTriggerBeginXact() to when the data structures are acutally used? Aren't we? Neither of those would be doing much work certainly.

Re: [HACKERS] Deferring some AtStart* allocations?

2014-06-29 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: On 2014-06-29 19:52:23 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: Why aren't we delaying allocations in e.g. AtStart_Inval(), AfterTriggerBeginXact() to when the data structures are acutally used? Aren't we? Neither of

Re: [HACKERS] Deferring some AtStart* allocations?

2014-06-29 Thread Andres Freund
On 2014-06-29 21:12:49 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-06-29 19:52:23 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: Why aren't we delaying allocations in e.g. AtStart_Inval(), AfterTriggerBeginXact() to when the data