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  (Jan Walter <john@commontongue.com>)
Список 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 по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Trees: integer[] outperformed by ltree
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: postgresql recommendation memory