Why Postgresql used ?

75 views
Skip to first unread message

Dmitry Ponyatov

unread,
May 8, 2017, 5:19:45 PM5/8/17
to opencog
I see odbc-postgresql & postgresql-client @ https://github.com/opencog/ocpkg/blob/master/debian/install-debian-dependencies.sh

I'm surprised why pgsql used ?
opencog nature tends to use some noSQL graph databases like neo4j

Mark Nuzz

unread,
May 8, 2017, 6:24:21 PM5/8/17
to ope...@googlegroups.com
I don't know the project's usage of Postgres, if there is even one,
but I think this is what you're looking for:
https://github.com/opencog/atomspace
> --
> You received this message because you are subscribed to the Google Groups
> "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to opencog+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opencog/9fa7463c-756c-4639-a16f-ebe71abd3086%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

AmeBel

unread,
May 9, 2017, 1:25:33 AM5/9/17
to opencog

Ben Goertzel

unread,
May 9, 2017, 1:30:00 AM5/9/17
to opencog
The in-RAM aspect of OpenCog uses our own custom Atomspace code...

For persistence to disk we use mainly postgres now, which works
fine... there is also a prototype Neo4j backing-store, which is less
complete and less tested...

Neo4j has a more restrictive license than postgres which is
undesirable from an OSS perspective. HGDB might be a good option to
explore, it's a hypergraph database with a better OSS license...

A big to-do for the future is to make a variety of Pattern Matcher
queries run against (some) backing store ... this would be done in the
Neo4j universe by auto-translating PM queries into Cypher queries, and
in the Postgres universe by auto-translating PM queries into
postgresql queries (and building appropriate indexes in postgres to
make these queries not insanely slow)

ben
> --
> You received this message because you are subscribed to the Google Groups
> "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to opencog+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opencog/c5973dcd-57c4-43b0-aaee-ecede0a9f19f%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



--
Ben Goertzel, PhD
http://goertzel.org

"I am God! I am nothing, I'm play, I am freedom, I am life. I am the
boundary, I am the peak." -- Alexander Scriabin

Linas Vepstas

unread,
May 9, 2017, 4:53:05 PM5/9/17
to opencog
The preliminary port to neo4j indicated it was 10x slower than postgres. I don't know the technical reason for this, it might just be due to a bad design.  Perhaps a good coder could fix this up.

Other nosql databases tend to be optimized for caching web pages or images, which are 10KBytes or larger (megabytes), and have absolutely terrible performance when the stored objects are just a few hundred bytes.  The opencog atoms are, for the most part, about 50-100 bytes in size, when stored.

postgres has sophisticated query mechanisms which most nosql databases do not support.  Opencog uses one of these, to quickly locate atoms at the end of graph edges. 

So these two requirements: ability to walk graph edges, and to be efficient/fast for small objects, are currently the main requirements. MariaDB can't do the first, and most nosql cant do the second.

--linas


--
You received this message because you are subscribed to the Google Groups "opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opencog+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
Visit this group at https://groups.google.com/group/opencog.

Andi

unread,
May 10, 2017, 5:02:40 AM5/10/17
to opencog, linasv...@gmail.com
linas, ty for this precise info!
it helps me too


Am Dienstag, 9. Mai 2017 22:53:05 UTC+2 schrieb linas:
The preliminary port to neo4j indicated it was 10x slower than postgres. I don't know the technical reason for this, it might just be due to a bad design.  Perhaps a good coder could fix this up.

Other nosql databases tend to be optimized for caching web pages or images, which are 10KBytes or larger (megabytes), and have absolutely terrible performance when the stored objects are just a few hundred bytes.  The opencog atoms are, for the most part, about 50-100 bytes in size, when stored.

postgres has sophisticated query mechanisms which most nosql databases do not support.  Opencog uses one of these, to quickly locate atoms at the end of graph edges. 

So these two requirements: ability to walk graph edges, and to be efficient/fast for small objects, are currently the main requirements. MariaDB can't do the first, and most nosql cant do the second.

--linas

On Mon, May 8, 2017 at 4:19 PM, Dmitry Ponyatov <dpon...@gmail.com> wrote:
I see odbc-postgresql & postgresql-client @ https://github.com/opencog/ocpkg/blob/master/debian/install-debian-dependencies.sh

I'm surprised why pgsql used ?
opencog nature tends to use some noSQL graph databases like neo4j

--
You received this message because you are subscribed to the Google Groups "opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opencog+u...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages