From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Kaare Rasmussen <kaare(at)jasonic(dot)dk>, PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: json indexing and data types |
Date: | 2015-12-03 14:25:53 |
Message-ID: | CAHyXU0xqA6X=1PWGek0=q4mNHxMv4a2eP=QERAPaJgy4aP98pQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Dec 2, 2015 at 10:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> (Having said that, it sure looks to me like JSON's idea of a number is
> float/numeric, not merely int. Are you sure you need more capability
> in that department, and if so what exactly?)
Numeric range searching is good, but the numeric case isn't compelling
for me. Text string searching *is* compelling but is not as of yet
supported by jsquery. Arbitrary token searching would be ideal, but
I'd settle for left to to right matching.
Historically, GIN index searching with over jsquery with ranges or
pg_trgm has also given me heartburn with its "worst case" performance
behavior in that it could in depressingly common cases underperform
(sometimes grossly) brute force. This doesn't mesh well with the
'user supplied list of search terms' type of searching that we do a
lot of.
The situation of late for pg_trgm has gotten drastically better with
the triconsistent API optimizations. I haven't gotten around yet to
seeing if any of that magic has been sprinkled on jsquery.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2015-12-03 14:30:21 | Re: json indexing and data types |
Previous Message | Caleb Meredith | 2015-12-03 13:17:19 | Re: Can row level security policies also be implemented for views? |