| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Christophe Pettus <xof(at)thebuild(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: jsonb and nested hstore |
| Date: | 2014-02-28 22:12:48 |
| Message-ID: | CAM3SWZSAGjQM8szL3XOetUNHQd5fcbQzo4L2B5yXjXjEeAuFtg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Feb 28, 2014 at 1:38 PM, Christophe Pettus <xof(at)thebuild(dot)com> wrote:
> jsonb is significantly faster than json even without indexing; there are plenty of reasons to have jsonb even if we don't initially have indexing operations for it.
That may be true, although I think that that's still very disappointing.
In order to make a rational decision to do the work incrementally, we
need to know what we're putting off until 9.5. AFAICT, we have these
operator classes that work fine with jsonb for the purposes of
hstore-style indexing (the hstore operator classes). Wasn't that the
point? When there is a dedicated set of jsonb operator classes, what
will be different about them, other than the fact that they won't be
hstore operator classes? A decision predicated on waiting for those to
come in 9.5 must consider what we're actually waiting for, and right
now that seems very hazy.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2014-02-28 22:13:40 | Re: patch: option --if-exists for pg_dump |
| Previous Message | Pavel Stehule | 2014-02-28 22:04:10 | Re: proposal: new long psql parameter --on-error-stop |