Re: Trees: integer[] outperformed by ltree

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Jan Walter <john(at)commontongue(dot)com>
Cc: postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Trees: integer[] outperformed by ltree
Date: 2013-11-05 19:51:18
Message-ID: CAHyXU0yZFKSFLr2med6q4Nokg0tsz0OHhEcFT2jUo0VeN28V6A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Nov 5, 2013 at 11:30 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Tue, Nov 5, 2013 at 6:25 AM, Jan Walter <john(at)commontongue(dot)com> wrote:
>> Hi,
>>
>> I am in a need of a very robust (esp. fast in read, non-blocking in update)
>> tree structure storage (95% trees are of depth <4, current max. is 12). We
>> have 10k-100k trees now, millions in the future.
>> I made many tests, benchmarks of usual operations, and after all,
>> materialized path ('1.5.3' path notation) seems most promising.
>
> materialized path approaches tend to be ideal if the tree remains
> relatively static and is not too deep. The downside with matpath is
> that if a you have to move a node around in the tree, then all the
> child elements paths' have to be expensively updated. I bring this up
> as it relates to your 'non-blocking in update' requirement: in matpath
> an update to parent can update an unbounded number of records.

hm, why do you need gist/gin for the int[] formulation? what are your
lookup requirements? with int[] you can typically do contains with
simple btree.

merlin

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Josh Berkus 2013-11-05 19:59:57 Re: postgresql recommendation memory
Previous Message Merlin Moncure 2013-11-05 17:30:27 Re: Trees: integer[] outperformed by ltree