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
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
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
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.
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
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
+
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
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
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,
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
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
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
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
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
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
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
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.
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(),
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
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.
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
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
22 matches
Mail list logo