On 01/15/2015 09:57 PM, Robert Haas wrote:
On Thu, Jan 15, 2015 at 3:08 AM, Michael Paquier
wrote:
On Mon, Dec 22, 2014 at 7:31 PM, Heikki Linnakangas
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 out
On Thu, Jan 15, 2015 at 3:08 AM, Michael Paquier
wrote:
> On Mon, Dec 22, 2014 at 7:31 PM, Heikki Linnakangas
> 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?
On Mon, Dec 22, 2014 at 7:31 PM, Heikki Linnakangas
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 mailing list (pgsql-hacke
On 12/16/2014 10:41 PM, Jeff Janes wrote:
On Wed, Dec 10, 2014 at 3:46 PM, Robert Haas wrote:
On Wed, Dec 10, 2014 at 3:28 PM, Heikki Linnakangas
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 addition to
On Wed, Dec 10, 2014 at 3:46 PM, Robert Haas wrote:
>
> On Wed, Dec 10, 2014 at 3:28 PM, Heikki Linnakangas
> 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 addition to the semicolon, it doesn
On Wed, Dec 10, 2014 at 3:28 PM, Heikki Linnakangas
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 before and it doesn't
On 12/10/2014 08:35 PM, Robert Haas wrote:
On Wed, Dec 10, 2014 at 12:57 PM, Heikki Linnakangas
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
o
On Wed, Dec 10, 2014 at 12:57 PM, Heikki Linnakangas
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, instead of one for wa
On 12/10/2014 06:56 PM, Robert Haas wrote:
On Wed, Dec 10, 2014 at 9:49 AM, Robert Haas 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
On Wed, Dec 10, 2014 at 9:49 AM, Robert Haas 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 very much; I'm comfor
On Wed, Dec 10, 2014 at 7:34 AM, Heikki Linnakangas
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
>>> downward. What's
On 12/09/2014 10:35 PM, Robert Haas wrote:
On Mon, Dec 8, 2014 at 9:31 AM, Robert Haas wrote:
On Mon, Dec 8, 2014 at 4:56 AM, Heikki Linnakangas
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
own
On Mon, Dec 8, 2014 at 9:31 AM, Robert Haas wrote:
> On Mon, Dec 8, 2014 at 4:56 AM, Heikki Linnakangas
> 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
On Mon, Dec 8, 2014 at 4:56 AM, Heikki Linnakangas
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
> them, and you have
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 wrote:
Alvaro Herrera 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
[ reviving a very old thread ]
On Tue, Feb 10, 2009 at 4:11 PM, Tom Lane wrote:
> Alvaro Herrera 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 p
Jeff Davis 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
there was any
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 c
Jeff Davis 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 advances.
On Wed, 2009-02-11 at 10:20 -0500, Robert Haas wrote:
> On Tue, Feb 10, 2009 at 3:06 PM, Jeff Davis 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
On Tue, Feb 10, 2009 at 3:06 PM, Jeff Davis 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 pgsql-hackers mailin
Alvaro Herrera 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 SnapshotResetXmin already know they
r
Tom Lane wrote:
> Jeff Davis 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
Jeff Davis 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 having it assume that
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 foo;
25 matches
Mail list logo
