Peter Geoghegan pe...@2ndquadrant.com writes:
On 8 December 2012 14:41, Andres Freund and...@2ndquadrant.com wrote:
Is anybody planning to work on this? There hasn't been any activity
since the beginning of the CF and it doesn't look like there is much
work left?
I took another look at this.
On 17 January 2013 18:22, Tom Lane t...@sss.pgh.pa.us wrote:
Applied with some changes:
Thank you. That feedback is useful.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list
Peter Geoghegan pe...@2ndquadrant.com writes:
I took another look at this.
Since Greg S. seems to have lost interest in committing this, I am
picking it up.
My strategy for preventing overflow is to use a uint64, and to use
Min()/Max() as appropriate. As Robert mentioned, even a 64-bit
On 8 December 2012 14:41, Andres Freund and...@2ndquadrant.com wrote:
Is anybody planning to work on this? There hasn't been any activity
since the beginning of the CF and it doesn't look like there is much
work left?
I took another look at this.
The growmemtuples bool from Jeff's original
Hi,
On 2012-11-21 14:52:18 -0800, Jeff Janes wrote:
On Thu, Nov 15, 2012 at 11:16 AM, Robert Haas robertmh...@gmail.com wrote:
So what's next here? Do you want to work on these issue some more?
Or does Jeff?
This has been rewritten enough that I no longer feel much ownership of it.
On Thu, Nov 15, 2012 at 11:16 AM, Robert Haas robertmh...@gmail.com wrote:
So what's next here? Do you want to work on these issue some more?
Or does Jeff?
This has been rewritten enough that I no longer feel much ownership of it.
I'd prefer to leave it to Peter or Greg S., if they are
On Thu, Nov 15, 2012 at 2:54 PM, Greg Stark st...@mit.edu wrote:
On Thu, Nov 15, 2012 at 7:36 PM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
On 15 November 2012 19:16, Robert Haas robertmh...@gmail.com wrote:
So what's next here? Do you want to work on these issue some more?
Or does Jeff?
On Thu, Nov 15, 2012 at 4:13 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 15 November 2012 19:54, Greg Stark st...@mit.edu wrote:
The only concern I had was about the behaviour after it did the
special case. I didn't want it to keep doing the math and trying to
grow again a little bit
On Tue, Oct 16, 2012 at 4:47 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
The same basic strategy for sizing the tuplesort memtuples array in
also exists in tuplestore. I wonder if we should repeat this there? I
suppose that that could follow later.
I think it'd be a good idea to either
On 15 November 2012 16:09, Robert Haas robertmh...@gmail.com wrote:
[Lots of complicated commentary on tuplesort variables]
Whew. In the attached version, I
updated the comment to reflect this, and also reversed the order of
the if/else block to put the shorter and more common case first,
On 15 November 2012 16:09, Robert Haas robertmh...@gmail.com wrote:
I'm still not too sure why this part is OK:
/* This may not be our first time through */
if (newmemtupsize = memtupsize)
return false;
Suppose we enlarge the memtuples array by something other
On Thu, Nov 15, 2012 at 12:14 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 15 November 2012 16:09, Robert Haas robertmh...@gmail.com wrote:
[Lots of complicated commentary on tuplesort variables]
Whew. In the attached version, I
updated the comment to reflect this, and also reversed
On 15 November 2012 18:13, Robert Haas robertmh...@gmail.com wrote:
Ah, yeah. I wondered in passing about that but forgot to follow up on
it. The problem specifically is that the intermediate result
memtupsize * newmemtuples might overflow. I believe that the old
memtupsize can never be
On Thu, Nov 15, 2012 at 2:13 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 15 November 2012 18:13, Robert Haas robertmh...@gmail.com wrote:
Ah, yeah. I wondered in passing about that but forgot to follow up on
it. The problem specifically is that the intermediate result
memtupsize *
On 15 November 2012 19:16, Robert Haas robertmh...@gmail.com wrote:
So what's next here? Do you want to work on these issue some more?
Or does Jeff? I'd like to see this go in, but I'm not sure I have the
bandwidth to do the legwork myself.
I'll take another look. No elegant solution
On Thu, Nov 15, 2012 at 7:36 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 15 November 2012 19:16, Robert Haas robertmh...@gmail.com wrote:
So what's next here? Do you want to work on these issue some more?
Or does Jeff? I'd like to see this go in, but I'm not sure I have the
bandwidth
On 15 November 2012 19:54, Greg Stark st...@mit.edu wrote:
The only concern I had was about the behaviour after it did the
special case. I didn't want it to keep doing the math and trying to
grow again a little bit every tuple. I think I was leaning to putting
the magic flag back.
The
Greg Stark escribió:
On Tue, Oct 16, 2012 at 9:47 PM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
The patch will now been marked ready for committer. Does this need
doc changes, in light of what is arguably a behavioural difference?
You only mentioned release notes.
I'm happy to look
On 16 October 2012 21:47, Peter Geoghegan pe...@2ndquadrant.com wrote:
The same basic strategy for sizing the tuplesort memtuples array in
also exists in tuplestore. I wonder if we should repeat this there? I
suppose that that could follow later.
Incidentally, the basis of this remark is
On 14 October 2012 09:19, Simon Riggs si...@2ndquadrant.com wrote:
This is a very useful optimisation, for both the low and the high end.
Well, I'm about ready to mark this one ready for committer. There is
this outstanding issue in my revision of August 17th, though:
+ /*
+
On 16 October 2012 13:42, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 14 October 2012 09:19, Simon Riggs si...@2ndquadrant.com wrote:
This is a very useful optimisation, for both the low and the high end.
Well, I'm about ready to mark this one ready for committer. There is
this
On 16 October 2012 14:24, Simon Riggs si...@2ndquadrant.com wrote:
If you describe in detail that it is a heuristic and why that is
proposed over other approaches that should be sufficient for future
generations to read and understand.
I've done so, in the attached revision. Things have been
On Tue, Oct 16, 2012 at 9:47 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
The patch will now been marked ready for committer. Does this need
doc changes, in light of what is arguably a behavioural difference?
You only mentioned release notes.
I'm happy to look at this one, probably next
On 16 October 2012 22:18, Greg Stark st...@mit.edu wrote:
That's assuming my committer bits haven't lapsed and people are ok
with me stepping back into things?
I personally have no objections.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training
On 17 August 2012 00:26, Peter Geoghegan pe...@2ndquadrant.com wrote:
This patch works by not doubling the size of state-memtupsize when
available memory is less than half of allowed memory (i.e. we are one
call to grow_memtuples() away from reporting ). Rather, in that
situation, it is set
On 14 October 2012 09:19, Simon Riggs si...@2ndquadrant.com wrote:
This is a very useful optimisation, for both the low and the high end.
I suppose it's possible to not think of it as an optimisation at all.
Rather, it could be considered a way of making tuplesort really use
the work_mem
On Thu, Aug 16, 2012 at 4:26 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 27 July 2012 16:39, Jeff Janes jeff.ja...@gmail.com wrote:
Can you suggest a benchmark that will usefully exercise this patch?
I think the given sizes below work on most 64 bit machines.
My apologies for not
Do you intend to follow through with this, Jeff?
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 27 July 2012 16:39, Jeff Janes jeff.ja...@gmail.com wrote:
Can you suggest a benchmark that will usefully exercise this patch?
I think the given sizes below work on most 64 bit machines.
My apologies for not getting around to taking a look at this sooner.
I tested this patch on my x86_64
On Wed, Jul 25, 2012 at 2:51 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 3 March 2012 20:22, Jeff Janes jeff.ja...@gmail.com wrote:
Add it all up, and instead of pre-reading 32 consecutive 8K blocks, it
pre-reads only about 1 or 2 consecutive ones on the final merge. Now
some of those
On 3 March 2012 20:22, Jeff Janes jeff.ja...@gmail.com wrote:
Add it all up, and instead of pre-reading 32 consecutive 8K blocks, it
pre-reads only about 1 or 2 consecutive ones on the final merge. Now
some of those could be salvaged by the kernel keeping track of
multiple interleaved read
On Sat, Mar 3, 2012 at 3:22 PM, Jeff Janes jeff.ja...@gmail.com wrote:
When sorting small tuples, the memtuples array can use a substantial
fraction of the total per-tuple memory used. (In the case of pass by
value, it is all of it)
The way it grows leads to sub-optimal memory usage.
Greg, I
When sorting small tuples, the memtuples array can use a substantial
fraction of the total per-tuple memory used. (In the case of pass by
value, it is all of it)
The way it grows leads to sub-optimal memory usage.
In one case, if it can grow by 1.999 x, but not by 2 x, we just give
up and use
33 matches
Mail list logo
