From: Tom Lane <tgl@sss.pgh.pa.us>
To: Marcin Krupowicz <ma@rcin.me>
cc: pgsql-performance@lists.postgresql.org
Subject: Re: Adding non-selective key to jsonb query @> reduces performance?
In-reply-to: 
 <CAK1Niaz+bHjM6yQ2HTwcTtFrrAJKZkB28nar7C-spygjEyOv3w@mail.gmail.com>
References: 
 <CAK1Niaz+bHjM6yQ2HTwcTtFrrAJKZkB28nar7C-spygjEyOv3w@mail.gmail.com>
Comments: In-reply-to Marcin Krupowicz <ma@rcin.me>
	message dated "Wed, 08 Jun 2022 11:55:44 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1623001.1654698723.1@sss.pgh.pa.us>
Date: Wed, 08 Jun 2022 10:32:03 -0400
Message-ID: <1623002.1654698723@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1623002.1654698723%40sss.pgh.pa.us>
Precedence: bulk

Marcin Krupowicz <ma@rcin.me> writes:
> However this one, is slow:

> Q2
> select count(*) from tbl where row @> '{"SELECTIVE_COL":
> "SearchValue", "DATE": "20220606", "NON_SELECTIVE_COL": "Abc"}'::jsonb
> It takes 17ms

> Note that the only difference is adding one more - not very unique -
> key. If in Q2 I replaced NON_SELECTIVE_COL with another selective
> column, it's becoming fast again.

This doesn't surprise me a whole lot based on what I know of GIN.
It's going to store sets of TIDs associated with each key or value
mentioned in the data, and then a query will have to AND the sets
of TIDs for keys/values mentioned in the query.  That will take
longer when some of those sets are big.

It might be worth experimenting with an index built using the
non-default jsonb_path_ops opclass [1].  I'm not sure if that'd be
faster for this scenario, but it seems worth trying.

			regards, tom lane

[1] https://www.postgresql.org/docs/current/datatype-json.html#JSON-INDEXING