On 02/17/2015 02:56 PM, Alexander Korotkov wrote:
Hi!
On Mon, Dec 22, 2014 at 1:07 PM, Heikki Linnakangas
wrote:
Ok, thanks for the review! I have committed this, with some cleanup and
more comments added.
ISTM that checks in pairingheap_GISTSearchItem_cmp is incorrect. This
function shoul
Hi!
On Mon, Dec 22, 2014 at 1:07 PM, Heikki Linnakangas wrote:
> Ok, thanks for the review! I have committed this, with some cleanup and
> more comments added.
>
ISTM that checks in pairingheap_GISTSearchItem_cmp is incorrect. This
function should perform inverse comparison. Thus, if item a sho
On 12/20/2014 10:50 PM, Peter Geoghegan wrote:
On Wed, Dec 17, 2014 at 6:07 AM, Heikki Linnakangas
wrote:
How about adding a src/backend/lib/README for that, per attached?
I took a quick look at this. Some observations:
* I like the idea of adding a .../lib README. However, the README
fails
On Wed, Dec 17, 2014 at 6:07 AM, Heikki Linnakangas
wrote:
> How about adding a src/backend/lib/README for that, per attached?
I took a quick look at this. Some observations:
* I like the idea of adding a .../lib README. However, the README
fails to note that ilist.c implements an *integrated* l
On 12/15/2014 03:14 PM, Andres Freund wrote:
If we add another heap implementation we probably should at least hint
at the different advantages somewhere.
How about adding a src/backend/lib/README for that, per attached?
- Heikki
diff --git a/src/backend/lib/Makefile b/src/backend/lib/Makefil
On 12/15/2014 11:59 PM, Jeff Janes wrote:
On Mon, Dec 15, 2014 at 5:08 AM, Heikki Linnakangas
wrote:
Here's a new version of the patch. It now uses the same pairing heap code
that I posted in the other thread ("advance local xmin more aggressivley",
http://www.postgresql.org/message-id/5488ac
On Mon, Dec 15, 2014 at 5:08 AM, Heikki Linnakangas wrote:
Here's a new version of the patch. It now uses the same pairing heap code
> that I posted in the other thread ("advance local xmin more aggressivley",
> http://www.postgresql.org/message-id/5488acf0.8050...@vmware.com). The
> pairingheap_
On 2014-12-15 15:08:28 +0200, Heikki Linnakangas wrote:
> +/*-
> + *
> + * pairingheap.c
> + * A Pairing Heap implementation
> + *
> + * Portions Copyright (c) 2012-2014, PostgreSQL Global Development Group
> + *
> + * IDEN
On 12/15/2014 03:49 AM, Michael Paquier wrote:
On Thu, Dec 11, 2014 at 12:50 AM, Heikki Linnakangas
wrote:
On 01/28/2014 04:12 PM, Alexander Korotkov wrote:
3. A binary heap would be a better data structure to buffer the
rechecked
values. A Red-Black tree allows random insertions and deletio
On Thu, Dec 11, 2014 at 12:50 AM, Heikki Linnakangas
wrote:
> On 01/28/2014 04:12 PM, Alexander Korotkov wrote:
>>>
>>> >3. A binary heap would be a better data structure to buffer the
>>> > rechecked
>>> >values. A Red-Black tree allows random insertions and deletions, but in
>>> >this case you n
On 12/10/2014 10:59 PM, Arthur Silva wrote:
It may be better to replace the lib/binaryheap altogether as it offers
comparable/better performance.
It's not always better. A binary heap is more memory-efficient, for
starters.
There are only two uses of lib/binaryheap: reorderbuffer.c and merge
On Wed, Dec 10, 2014 at 1:50 PM, Heikki Linnakangas wrote:
> On 01/28/2014 04:12 PM, Alexander Korotkov wrote:
>
>> >3. A binary heap would be a better data structure to buffer the rechecked
>>> >values. A Red-Black tree allows random insertions and deletions, but in
>>> >this case you need to in
On 01/28/2014 04:12 PM, Alexander Korotkov wrote:
>3. A binary heap would be a better data structure to buffer the rechecked
>values. A Red-Black tree allows random insertions and deletions, but in
>this case you need to insert arbitrary values but only remove the minimum
>item. That's exactly wh
13 matches
Mail list logo
