On 01/15/2015 09:57 PM, Robert Haas wrote:
On Thu, Jan 15, 2015 at 3:08 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Mon, Dec 22, 2014 at 7:31 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Here's an updated version, rebased over the pairing heap code that I just
committed,
On Thu, Jan 15, 2015 at 3:08 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Mon, Dec 22, 2014 at 7:31 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Here's an updated version, rebased over the pairing heap code that I just
committed, and fixing those bugs.
So, are we reaching
On Mon, Dec 22, 2014 at 7:31 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Here's an updated version, rebased over the pairing heap code that I just
committed, and fixing those bugs.
So, are we reaching an outcome for the match happening here?
--
Michael
--
Sent via pgsql-hackers
On 12/16/2014 10:41 PM, Jeff Janes wrote:
On Wed, Dec 10, 2014 at 3:46 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 10, 2014 at 3:28 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Care to code it up?
Here you are.
That was quick.
You need to add a semicolon to the end
On Wed, Dec 10, 2014 at 3:46 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 10, 2014 at 3:28 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Care to code it up?
Here you are.
That was quick.
You need to add a semicolon to the end of line 20 in pairingheap.c.
In
On 12/09/2014 10:35 PM, Robert Haas wrote:
On Mon, Dec 8, 2014 at 9:31 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 8, 2014 at 4:56 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I don't immediately see the problem either, but I have to say that
grovelling through all the
On Wed, Dec 10, 2014 at 7:34 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
1. I don't really see why resource owners shouldn't be traversed like
that. They are clearly intended to form a hierarchy, and there's
existing code that recurses through the hierarchy from a given level
On Wed, Dec 10, 2014 at 9:49 AM, Robert Haas robertmh...@gmail.com wrote:
I guess this bears some further thought. I certainly don't like the
fact that this makes the whole system crap out at a lower number of
subtransactions than presently. The actual performance numbers don't
bother me
On 12/10/2014 06:56 PM, Robert Haas wrote:
On Wed, Dec 10, 2014 at 9:49 AM, Robert Haas robertmh...@gmail.com wrote:
I guess this bears some further thought. I certainly don't like the
fact that this makes the whole system crap out at a lower number of
subtransactions than presently. The
On Wed, Dec 10, 2014 at 12:57 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Clever. Could we use that method in ResourceOwnerReleaseInternal and
ResourceOwnerDelete, too? Might be best to have a
ResourceOwnerWalk(resowner, callback) function for walking all resource
owners in a tree,
On 12/10/2014 08:35 PM, Robert Haas wrote:
On Wed, Dec 10, 2014 at 12:57 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Clever. Could we use that method in ResourceOwnerReleaseInternal and
ResourceOwnerDelete, too? Might be best to have a
ResourceOwnerWalk(resowner, callback) function
On Wed, Dec 10, 2014 at 3:28 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Care to code it up?
Here you are.
That was quick.
You need to add a semicolon to the end of line 20 in pairingheap.c.
I wonder what the worst case for this is. I tried it on your
destruction test case from
On Mon, Dec 8, 2014 at 9:31 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 8, 2014 at 4:56 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I don't immediately see the problem either, but I have to say that
grovelling through all the resource owners seems ugly anyway. Resource
On 12/05/2014 05:05 PM, Robert Haas wrote:
[ reviving a very old thread ]
On Tue, Feb 10, 2009 at 4:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
For example, maybe we could keep track of counts of snapshots removed
since the last xmin
On Mon, Dec 8, 2014 at 4:56 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I don't immediately see the problem either, but I have to say that
grovelling through all the resource owners seems ugly anyway. Resource
owners are not meant to be traversed like that. And there could be a lot of
On Tue, Feb 10, 2009 at 3:06 PM, Jeff Davis pg...@j-davis.com wrote:
With the new snapshot maintenance code, it looks like we can advance the
xmin more aggressively.
Can you clarify the circumstances in which this patch would show a
benefit over the current system?
...Robert
--
Sent via
On Wed, 2009-02-11 at 10:20 -0500, Robert Haas wrote:
On Tue, Feb 10, 2009 at 3:06 PM, Jeff Davis pg...@j-davis.com wrote:
With the new snapshot maintenance code, it looks like we can advance the
xmin more aggressively.
Can you clarify the circumstances in which this patch would show a
Jeff Davis pg...@j-davis.com writes:
On Wed, 2009-02-11 at 10:20 -0500, Robert Haas wrote:
Can you clarify the circumstances in which this patch would show a
benefit over the current system?
In the current code, if the process is always holding at least one
snapshot, the process' xmin never
On Wed, 2009-02-11 at 12:20 -0500, Tom Lane wrote:
You pointed out the case of opening a cursor in a read-committed
transaction, and then closing it before end of transaction, as a
place where your patch could hope to improve matters. Are there
others? Could your application be made to
Jeff Davis pg...@j-davis.com writes:
I could imagine some situations that this could be more useful in the
future. For instance, Hot Standby will increase the consequences of not
advancing xmin when it's possible to do so.
The question wasn't really about the consequences; it was about whether
With the new snapshot maintenance code, it looks like we can advance the
xmin more aggressively.
For instance:
S1:
INSERT INTO foo VALUES(1);
S2:
BEGIN;
DECLARE c1 CURSOR FOR SELECT i FROM foo;
S1:
DELETE FROM foo;
S2:
DECLARE c2 CURSOR FOR SELECT i FROM foo;
CLOSE c1;
S1:
VACUUM VERBOSE
Jeff Davis pg...@j-davis.com writes:
With the new snapshot maintenance code, it looks like we can advance the
xmin more aggressively.
The original design for that contemplated having snapmgr.c track
all the snapshots (cf the comment for RegisteredSnapshots). I don't
particularly care for
Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
With the new snapshot maintenance code, it looks like we can advance the
xmin more aggressively.
The original design for that contemplated having snapmgr.c track
all the snapshots (cf the comment for RegisteredSnapshots). I don't
Alvaro Herrera alvhe...@commandprompt.com writes:
For example, maybe we could keep track of counts of snapshots removed
since the last xmin calculation, and only run this routine if the number
is different from zero (or some small positive integer).
I think most of the callers of
24 matches
Mail list logo
