From: | Tom Smith <tomsmith1989sk(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bill Moran <wmoran(at)potentialtech(dot)com>, PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: JSONB performance enhancement for 9.6 |
Date: | 2015-11-29 18:10:10 |
Message-ID: | CAKwSVFG3xdNYUNyPjinNgvCN3n+fUF4n_EzmMf0e_L1N8sM6Xw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi:
The goal is fast retrieval of a a field value with a row when the row is
already
picked, one scenario is download a particular field value (if exists) of
all rows in the table.
It is actually a very common use case of exporting data of several user
selected fields.
The performance is extremely slow.
Thanks
On Sun, Nov 29, 2015 at 12:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Bill Moran <wmoran(at)potentialtech(dot)com> writes:
> > Tom Smith <tomsmith1989sk(at)gmail(dot)com> wrote:
> >> Is there a plan for 9.6 to resolve the issue of very slow
> >> query/retrieval of jsonb fields when there are large number (maybe
> >> several thousands) of top level keys. Currently, if I save a large
> >> json document with top level keys of thousands and query/retrieve field
> >> values, the whole document has to be first decompressed and load to
> >> memory before searching for the specific field key/value.
>
> > I could be off-base here, but have you tried:
> > ATLER TABLE $table ALTER COLUMN $json_column SET STORAGE EXTERNAL;
>
> There is just about zero chance we'll ever worry about this for compressed
> columns. However, even the uncompressed case does currently involve
> loading the whole column value, as Tom says. We did consider the
> possibility of such an optimization when designing the JSONB storage
> format, but I don't know of anyone actively working on it.
>
> In any case, it's unlikely that it'd ever be super fast, since it's
> certainly going to involve at least a couple of TOAST fetches.
> Personally I'd be looking for a different representation. If there
> are specific fields that are known to be needed a lot, maybe functional
> indexes would help?
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Sterpu Victor | 2015-11-29 18:59:38 | Re: DISTINCT in STRING_AGG |
Previous Message | George Neuner | 2015-11-29 17:56:13 | Re: using a postgres table as a multi-writer multi-updater queue |