On Jul 31, 2015 4:22 AM, Jeremy Harris j...@wizmail.org wrote:
On 30/07/15 02:05, Peter Geoghegan wrote:
Since heapification is now a big fraction of the total cost of a sort
sometimes, even where the heap invariant need not be maintained for
any length of time afterwards, it might be
On Sat, Aug 1, 2015 at 9:49 AM, Jeremy Harris j...@wizmail.org wrote:
On 31/07/15 18:31, Robert Haas wrote:
On Fri, Jul 31, 2015 at 7:21 AM, Jeremy Harris j...@wizmail.org wrote:
Heapification is O(n) already, whether siftup (existing) or down.
That's not my impression, or what Wikipedia
On Sat, Aug 1, 2015 at 9:56 AM, Andres Freund and...@anarazel.de wrote:
On 2015-07-31 13:31:54 -0400, Robert Haas wrote:
On Fri, Jul 31, 2015 at 7:21 AM, Jeremy Harris j...@wizmail.org wrote:
Heapification is O(n) already, whether siftup (existing) or down.
That's not my impression, or what
On 2015-07-31 13:31:54 -0400, Robert Haas wrote:
On Fri, Jul 31, 2015 at 7:21 AM, Jeremy Harris j...@wizmail.org wrote:
Heapification is O(n) already, whether siftup (existing) or down.
That's not my impression, or what Wikipedia says. Source?
Building a binary heap via successive
On 31/07/15 18:31, Robert Haas wrote:
On Fri, Jul 31, 2015 at 7:21 AM, Jeremy Harris j...@wizmail.org wrote:
Heapification is O(n) already, whether siftup (existing) or down.
That's not my impression, or what Wikipedia says. Source?
Measurements done last year:
On Fri, Jul 31, 2015 at 7:21 AM, Jeremy Harris j...@wizmail.org wrote:
Heapification is O(n) already, whether siftup (existing) or down.
That's not my impression, or what Wikipedia says. Source?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
On 30/07/15 02:05, Peter Geoghegan wrote:
Since heapification is now a big fraction of the total cost of a sort
sometimes, even where the heap invariant need not be maintained for
any length of time afterwards, it might be worth revisiting the patch
to make that an O(n) rather than a O(log n)
On 30 July 2015 at 12:26, Greg Stark st...@mit.edu wrote:
On Thu, Jul 30, 2015 at 12:09 PM, Heikki Linnakangas hlinn...@iki.fi
wrote:
True, you need a heap to hold the next tuple from each tape in the merge
step. To avoid exceeding work_mem, you'd need to push some tuples from the
On Thu, Jul 30, 2015 at 4:26 AM, Greg Stark st...@mit.edu wrote:
I'm a bit confused where the big win comes from though. Is what's going on
that the external sort only exceeded memory by a small amount so nearly all
the tuples are still in memory?
Yes, that's why this can be much faster just
On Thu, Jul 30, 2015 at 12:09 PM, Heikki Linnakangas hlinn...@iki.fi
wrote:
True, you need a heap to hold the next tuple from each tape in the merge
step. To avoid exceeding work_mem, you'd need to push some tuples from the
in-memory array to the tape to make room for that. In practice,
10 matches
Mail list logo
