Re: Graph datatype addition

Поиск
Список
Период
Сортировка
От Florian Pflug
Тема Re: Graph datatype addition
Дата
Msg-id 689CA744-6648-4AFD-BF8C-0FE6E4CA00EB@phlo.org
обсуждение исходный текст
Ответ на Re: Graph datatype addition  (Atri Sharma <atri.jiit@gmail.com>)
Ответы Re: Graph datatype addition
Re: Graph datatype addition
Список pgsql-hackers
On Apr29, 2013, at 21:00 , Atri Sharma <atri.jiit@gmail.com> wrote:
> I think we find work arounds or make shifts at the moment if we need
> to use graphs in our database in postgres. If we have a datatype
> itself, with support for commonly used operations built inside the
> type itself, that will greatly simplify user's tasks, and open up a
> whole new avenue of applications for us, such as recommender systems,
> social network analysis, or anything that can be done with graphs.

Usually though, you'd be interested a large graphs which include
information for lots of records (e.g., nodes are individual users,
or products, or whatever). A graph datatype is not well suited for
that, because it'd store each graph as a single value, and updating
the graph would mean rewriting that whole value. If you're e.g. doing
social network analysis, and each new edge between two users requires
you to pull the whole graph from disk, update it, and write it back,
you'll probably hit problems once you reach a few hundred users or
so… Which really isn't a lot for that kind of application.

I'd love to see more support for those kinds of queries in postgres,
(although WITH RECURSIVE already was a *huge* improvement in this
area!). But storing each graph as a graph type would do isn't the
way forward, IMHO.

best regards,
Florian Pflug




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: [PATCH] add --throttle option to pgbench
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: Remaining beta blockers