Re: Trees: integer[] outperformed by ltree
От | Merlin Moncure |
---|---|
Тема | Re: Trees: integer[] outperformed by ltree |
Дата | |
Msg-id | CAHyXU0wdt2-p9u_0k2mQ5O7dsGpzqEL=yYZWyy1NavyoQwLy_w@mail.gmail.com обсуждение исходный текст |
Ответ на | Trees: integer[] outperformed by ltree (Jan Walter <john@commontongue.com>) |
Ответы |
Re: Trees: integer[] outperformed by ltree
|
Список | pgsql-performance |
On Tue, Nov 5, 2013 at 6:25 AM, Jan Walter <john@commontongue.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
В списке pgsql-performance по дате отправления: