"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes:
> I apparently didn't express myself very well, since you seem to have
> *completely* missed my point.  I know we can do tsearch2 searches
> against XML, or JSON, or YAML, or (insert next week's new favorite
> format here).  What we can't currently do efficiently is search for
> particular values in some particular place in the hierarchy of a
> document.  I've had loads of fun approximating it with regular
> expressions, but some days I'd like life to be easier.

> What I was arguing for is a new type which would represent the
> structure in a fashion which was independent of the particular text
> format and was efficient to traverse hierarchically.  Done right,
> that would map well to GiST.  Although, thinking about that some
> more, perhaps there would be a way to create a GiST index suitable
> for that straight from the XML text, and avoid the sharded column. 
> A GiST index actually seems pretty close to what such a structure
> would look like anyway....

FWIW, GIN might be a more natural match, at least for the cases where
"place in the document" has a scalar value.  If you need to search for
"place" with something other than equality or prefix match semantics,
maybe not.

But in any case I think your point is that this is an indexing problem,
and whether the full document in the table column is pre-parsed or not
isn't all that relevant for performance.  I agree.  tsearch2 is really a
precedent for your argument, not a distinct approach, because it doesn't
expect pre-parsed text columns either.

                        regards, tom lane

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to