> On 08-07-2021, at 17:13, Manuel Weitzman wrote:
>
> Option A: Use a common table expression to "force" the usage of
> test_json_data_idx
>
>WITH json_matching_rows AS (
>SELECT t.*
>FROM test ti
>WHERE t.json_data @> '{"book":{"title":"In Search of Lost Time"}}'
> On 08-07-2021, at 17:13, Manuel Weitzman wrote:
>
> I'd recommend you using cursors for pagination in general (I know it
> may not be possible for you, just wanted to explain as it could be
> useful).
By the way, I mean cursor pagination as the general concept.
I'm not talking about Postgre
> On 08-07-2021, at 04:26, Joel Frid wrote:
>
> Hi,
>
> On my production environment (PostgreSQL 13.3), one of my queries runs very
> slow, about 2 minutes.
> I noticed that it does not use an execution plan that I anticapited it would.
>
> The query is :
>
> SELECT t.*
> FROM test t
> W
Hi,
On my production environment (PostgreSQL 13.3), one of my queries runs very
slow, about 2 minutes.
I noticed that it does not use an execution plan that I anticapited it would.
The query is :
SELECT t.*
FROM test t
WHERE t."existe" IS true
and t.json_data" @> '{"book":{"title"
Hi,
On my production environment (PostgreSQL 13.3), one of my queries runs very
slow, about 2 minutes.
I noticed that it does not use an execution plan that I anticapited it would.
The query is :
SELECT t.*
FROM test t
WHERE t."existe" IS true
and t.json_data" @> '{"book":{"title"
