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
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 |