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 17:30:27
Message-ID: CAHyXU0wdt2-p9u_0k2mQ5O7dsGpzqEL=yYZWyy1NavyoQwLy_w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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.

merlin

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2013-11-05 19:51:18 Re: Trees: integer[] outperformed by ltree
Previous Message Jeff Janes 2013-11-05 16:10:19 Re: Slow index scan on B-Tree index over timestamp field