Re: Compressed TOAST Slicing

From: Paul Ramsey <pramsey(at)cleverelephant(dot)ca>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: rafia(dot)sabih(at)enterprisedb(dot)com, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Compressed TOAST Slicing
Date: 2019-02-19 23:09:39
Message-ID: CACowWR0pUkSbzkGz9-DowbcixdiPVdkpwjc_U08um+H2kdc6Fg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Feb 16, 2019 at 7:25 AM Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:

> Could we get an similarly optimized implementation of -> operator for JSONB as well?
> Are there any other potential uses? Best to fix em all up at once and then move on to other things. Thanks.

Oddly enough, I couldn't find many/any things that were sensitive to
left-end decompression. The only exception is "LIKE this%" which
clearly would be helped, but unfortunately wouldn't be a quick
drop-in, but a rather major reorganization of the regex handling.

I had a look at "->" and I couldn't see how a slice could be used to
make it faster? We don't a priori know how big a slice would give us
what we want. This again makes Stephen's case for an iterator, but of
course all the iterator benefits only come when the actual function at
the top (in this case the json parser) are also updated to be
iterative.

Committing this little change doesn't preclude an iterator, or even
make doing one more complicated... :)

P.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-02-19 23:11:21 More smarts about CoerceViaIO, and less stupidity about ArrayCoerceExpr
Previous Message Thomas Munro 2019-02-19 22:57:26 Re: Some thoughts on NFS