On 2012-12-05 10:49:35 -0800, Josh Berkus wrote: > > >> *) xmlpath/jsonpath do searching (and decomposition) but are very > >> clunky from sql perspective and probably absolutely nogo in terms if > >> GIST/GIN. postgres spiritually wants to do things via operators and > >> we should (if possible) at least consider that first > > Why is it a nogo for GiST? Ltree works, doesn't it? If we only support > equality lookups in what way is a JSON doc different from a collection > of ltree rows?
The space requirement for the paths are quite different. Its not that hard to build indexing support, its hard to build efficient support. The more you hide from postgres (i.e. behind a single very complex operator/function) the harder it is for the planner to detect whether your expression is indexable or not. > We'd probably want to use SP-GiST for better index size/performance, but > I don't see that this is impossible. Just some difficult code. I don't immediately see why SP-Gist would be be beneficial. What kind of access structure do you have in mind? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers