On Wed, Jun 08, 2022 at 09:44:08AM +0100, Paulo Silva wrote:
> But if I add an ORDER BY and a LIMIT something goes very wrong (Q2):
A somewhat common problem.
A common workaround is to change "ORDER BY a" to something like "ORDER BY a+0"
(if your framework will allow it).
> An EXPLAIN (ANALYZE,
Marcin Krupowicz 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
Hi,
The problem is that the query is generated by the framework, I'm not sure
if I can change anything on it. Any other way to influence planner?
Regards
Ranier Vilela escreveu no dia quarta, 8/06/2022 à(s)
12:40:
> Em qua., 8 de jun. de 2022 às 05:44, Paulo Silva
> escreveu:
>
>> Hi,
>>
>> I
Em qua., 8 de jun. de 2022 às 05:44, Paulo Silva
escreveu:
> Hi,
>
> I'm using PostgreSQL 14.3 and I'm getting strange behavior in a complex
> query generated by the Entity Framework.
>
> The inner (complex) query has a quick execution time:
>
> # SELECT "Extent1"."id", CAST ("Extent1"."date" AS
Hi,
I have a table "tbl" with a couple of columns. One of them is "row"
jsonb. It has a GIN index as per below. The table isn't particularly
large, in lower tens of GB. Each "row" has maybe 5-20 keys, nothing
crazy.
Now, when I query it with @> operator I get very different performance
depending o
Hi,
I'm using PostgreSQL 14.3 and I'm getting strange behavior in a complex
query generated by the Entity Framework.
The inner (complex) query has a quick execution time:
# SELECT "Extent1"."id", CAST ("Extent1"."date" AS timestamp) AS "C3"
FROM "dbo"."ng_content" AS "Extent1"
IN
