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