On Thu, Jun 28, 2012 at 6:01 PM, Daniel Farina dan...@heroku.com wrote:
On Thu, Jun 28, 2012 at 2:32 PM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
On 28 June 2012 22:22, Daniel Farina dan...@heroku.com wrote:
All in all, I don't think this can be a very productive discussion
unless
On Thu, Jun 28, 2012 at 08:17:53PM +0100, Peter Geoghegan wrote:
On 28 June 2012 20:00, Tom Lane t...@sss.pgh.pa.us wrote:
See VACUUM FULL for a recent counterexample --- we basically jacked it
up and drove a new implementation underneath, but we didn't change the
name, despite the fact
On 27 June 2012 23:01, Robert Haas robertmh...@gmail.com wrote:
1. Are there any call sites from which this should be disabled, either
because the optimization won't help, or because the caller is holding
a lock that we don't want them sitting on for a moment longer than
necessary? I think
On Thu, Jun 28, 2012 at 4:21 AM, Simon Riggs si...@2ndquadrant.com wrote:
Let's put this in now, without too much fiddling. There is already a
GUC to disable it, so measurements can be made to see if this causes
any problems.
If there are problems, we fix them. We can't second guess
On 28.06.2012 15:18, Robert Haas wrote:
On Thu, Jun 28, 2012 at 4:21 AM, Simon Riggssi...@2ndquadrant.com wrote:
2. Should we rename the GUCs, since this patch will cause them to
control WAL flush in general, as opposed to commit specifically?
Peter Geoghegan and Simon were arguing that we
On 28 June 2012 18:57, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
FWIW, I think commit_delay is just fine. In practice, it's mostly commits
that are affected, anyway. If we try to be more exact, I think it's just
going to be more confusing to users.
You think it will confuse
Peter Geoghegan pe...@2ndquadrant.com wrote:
Is anyone aware of a non-zero commit_delay in the wild today? I
personally am not.
http://archives.postgresql.org/pgsql-performance/2011-11/msg00083.php
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 28 June 2012 19:25, Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Peter Geoghegan pe...@2ndquadrant.com wrote:
Is anyone aware of a non-zero commit_delay in the wild today? I
personally am not.
http://archives.postgresql.org/pgsql-performance/2011-11/msg00083.php
In that thread,
On Thu, Jun 28, 2012 at 2:18 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
You think it will confuse users less if we start telling them to use
something that we have a very long history of telling them not to use?
I don't buy this line of reasoning at all. If we're going to rename
the GUC,
On 28 June 2012 19:55, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jun 28, 2012 at 2:18 PM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
You think it will confuse users less if we start telling them to use
something that we have a very long history of telling them not to use?
I don't
Robert Haas robertmh...@gmail.com writes:
On Thu, Jun 28, 2012 at 2:18 PM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
You think it will confuse users less if we start telling them to use
something that we have a very long history of telling them not to use?
I don't buy this line of
On 28 June 2012 20:00, Tom Lane t...@sss.pgh.pa.us wrote:
See VACUUM FULL for a recent counterexample --- we basically jacked it
up and drove a new implementation underneath, but we didn't change the
name, despite the fact that we were obsoleting a whole lot more folk
knowledge than exists
On Thu, Jun 28, 2012 at 2:58 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 28 June 2012 19:55, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jun 28, 2012 at 2:18 PM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
You think it will confuse users less if we start telling them to use
On 28 June 2012 20:55, Robert Haas robertmh...@gmail.com wrote:
I don't buy this line of reasoning at all. If we're going to rename
the GUC, it should be for accuracy, not PR value. If we start
renaming something every time we improve it, we're going to go nuts.
We improved lots of things in
On Thu, Jun 28, 2012 at 1:32 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
Anyway, it seems that no one other than you and I is very excited
about renaming this for whatever reason, so maybe we should leave it
at that.
I think not changing the name is a really bad decision, and I am
On 28 June 2012 22:22, Daniel Farina dan...@heroku.com wrote:
All in all, I don't think this can be a very productive discussion
unless someone just pitches a equal or better name overall in terms of
conciseness and descriptiveness. I'd rather optimize for those
attributes. Old advice is
On Thu, Jun 28, 2012 at 2:32 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 28 June 2012 22:22, Daniel Farina dan...@heroku.com wrote:
All in all, I don't think this can be a very productive discussion
unless someone just pitches a equal or better name overall in terms of
conciseness and
On Sat, Jun 2, 2012 at 10:44 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Tom Lane wrote:
Simon Riggs writes:
On 31 May 2012 15:00, Tom Lane wrote:
If we want to finish the beta cycle in a reasonable time period
and get back to actual development, we have to refrain from
adding
On 27 June 2012 23:01, Robert Haas robertmh...@gmail.com wrote:
1. Are there any call sites from which this should be disabled, either
because the optimization won't help, or because the caller is holding
a lock that we don't want them sitting on for a moment longer than
necessary? I think
Tom Lane wrote:
Simon Riggs writes:
On 31 May 2012 15:00, Tom Lane wrote:
If we want to finish the beta cycle in a reasonable time period
and get back to actual development, we have to refrain from
adding more possibly-destabilizing development work to 9.2. And
that is what this is.
In
This is a benchmark I performed on the same hardware, for tpc-b.sql,
with a commit_delay of 0 and 4000 for the patch:
http://tpcbdelay.staticloud.com/
There is a rather large improvement in throughput here. Robert
previously complained that our group commit implementation didn't do
very well on
On 30 May 2012 17:19, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 30 May 2012 15:25, Simon Riggs si...@2ndquadrant.com wrote:
1. It seems wrong to do it in xact_redo_commit_internal(). It won't
matter if commit_siblings0 since there won't be any other backends
with transaction IDs anyway,
On 31 May 2012 11:19, Simon Riggs si...@2ndquadrant.com wrote:
I've looked at this more closely now and I can see that the call to
XLogFlush() that is made from xact_redo_commit_internal() doesn't ever
actually flush WAL, so whether we delay or not is completely
irrelevant.
So un-agreed. No
On Thu, May 31, 2012 at 6:19 AM, Simon Riggs si...@2ndquadrant.com wrote:
I've looked at this more closely now and I can see that the call to
XLogFlush() that is made from xact_redo_commit_internal() doesn't ever
actually flush WAL, so whether we delay or not is completely
irrelevant.
So
On 31 May 2012 13:16, Robert Haas robertmh...@gmail.com wrote:
On Thu, May 31, 2012 at 6:19 AM, Simon Riggs si...@2ndquadrant.com wrote:
I've looked at this more closely now and I can see that the call to
XLogFlush() that is made from xact_redo_commit_internal() doesn't ever
actually flush
On 31 May 2012 13:16, Robert Haas robertmh...@gmail.com wrote:
On Thu, May 31, 2012 at 6:19 AM, Simon Riggs si...@2ndquadrant.com wrote:
Frankly, I think this whole thing should be pushed to 9.3. The
commit_delay and commit_siblings knobs suck, but they've sucked for a
long time, and it won't
On Thu, May 31, 2012 at 8:38 AM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 31 May 2012 13:16, Robert Haas robertmh...@gmail.com wrote:
On Thu, May 31, 2012 at 6:19 AM, Simon Riggs si...@2ndquadrant.com wrote:
Frankly, I think this whole thing should be pushed to 9.3. The
commit_delay
Simon Riggs si...@2ndquadrant.com writes:
On 31 May 2012 13:16, Robert Haas robertmh...@gmail.com wrote:
Frankly, I think this whole thing should be pushed to 9.3.
What matters is that we have a patch that provides a massive
performance gain in write performance in just a few lines of code,
On 31 May 2012 15:00, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On 31 May 2012 13:16, Robert Haas robertmh...@gmail.com wrote:
Frankly, I think this whole thing should be pushed to 9.3.
What matters is that we have a patch that provides a massive
Simon Riggs si...@2ndquadrant.com writes:
On 31 May 2012 15:00, Tom Lane t...@sss.pgh.pa.us wrote:
If we want to finish the beta cycle in a reasonable time period and get
back to actual development, we have to refrain from adding more
possibly-destabilizing development work to 9.2. And that
On 31 May 2012 14:58, Robert Haas robertmh...@gmail.com wrote:
Fixing regressions before release is essential; improving performance
is not - especially when the improvement relates to a little-used
feature that you were proposing to get rid of two weeks ago.
Yes, the fact that I wanted to get
On 31 May 2012 16:26, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 31 May 2012 16:23, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
In what way is it possibly destabilising?
I'm prepared to believe that it only affects performance, but it could
be
On 31 May 2012 16:23, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
In what way is it possibly destabilising?
I'm prepared to believe that it only affects performance, but it could
be destabilizing to that. It needs proper review and testing, and the
next CF
On 29 May 2012 17:58, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 29, 2012 at 12:47 PM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
Why do you think that doing this for all XLogFlush() callsites might
be problematic?
Well, consider the one in the background writer, for example.
On Wed, May 30, 2012 at 4:36 AM, Simon Riggs si...@2ndquadrant.com wrote:
When I read this the first time, I was in full agreement.
On closer inspection neither point is valid, though both points were
worth considering.
Well, consider the one in the background writer, for example. That's
On 30 May 2012 13:24, Robert Haas robertmh...@gmail.com wrote:
Most of those actually do look like reasonable places to try to get
grouped flushing behavior, but:
1. It seems wrong to do it in xact_redo_commit_internal(). It won't
matter if commit_siblings0 since there won't be any other
On 30 May 2012 13:24, Robert Haas robertmh...@gmail.com wrote:
OK, but there are a lot of places where we call XLogFlush(), and it's
far from obvious that it's a win to do this in all of those cases. At
least, nobody's done that analysis. XLogFlush is called from:
- WriteTruncateXlogRec(),
On 30 May 2012 15:25, Simon Riggs si...@2ndquadrant.com wrote:
1. It seems wrong to do it in xact_redo_commit_internal(). It won't
matter if commit_siblings0 since there won't be any other backends
with transaction IDs anyway, but if commit_siblings==0 then we'll
sleep for no possible
On 29.05.2012 04:18, Peter Geoghegan wrote:
The attached very simple patch moves the commit_delay +
commit_siblings sleep into XLogFlush, where the leader alone sleeps.
This appears to be a much more effective site for a delay.
Benchmark results, with and without a delay of 3000ms
On 29 May 2012 07:16, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 29.05.2012 04:18, Peter Geoghegan wrote:
Benchmark results, with and without a delay of 3000ms (commit_siblings
is 0 in both cases) are available from:
http://leadercommitdelay.staticloud.com
Sorry, I do
On Mon, May 28, 2012 at 9:18 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
The attached very simple patch moves the commit_delay +
commit_siblings sleep into XLogFlush, where the leader alone sleeps.
This appears to be a much more effective site for a delay.
This is a clever idea, but I
On 29 May 2012 17:10, Robert Haas robertmh...@gmail.com wrote:
This is a clever idea,
Thanks.
but I think it needs some fine-tuning: as
written, this will sleep for any flush, not just a flush of a commit
record. One idea might be to add a flag to XLogFlush indicating
whether a
On Tue, May 29, 2012 at 12:47 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
Why do you think that doing this for all XLogFlush() callsites might
be problematic?
Well, consider the one in the background writer, for example. That's
just a periodic flush, so I see no benefit in having it
On 29 May 2012 17:58, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 29, 2012 at 12:47 PM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
Why do you think that doing this for all XLogFlush() callsites might
be problematic?
Well, consider the one in the background writer, for example.
44 matches
Mail list logo
