Greetings,
i have tested both options ANY with string + parsing and simple array - and
there are cases when execution time 100+ times worse than IN
On Tue, Feb 23, 2021 at 12:23 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Monday, February 22, 2021, Oleksandr Voytsekhovskyy
>
Hi
út 23. 2. 2021 v 10:36 odesílatel Alexander Voytsekhovskyy <
young.in...@gmail.com> napsal:
> Thanks for suggestion
>
> with tmp tables there are another issue - there are already 5-6 tables and
> 2-3 IN filters. If i will replace them with tmp tables it may hit query
> planner limits and it w
Thanks for suggestion
with tmp tables there are another issue - there are already 5-6 tables and
2-3 IN filters. If i will replace them with tmp tables it may hit query
planner limits and it will become to produce terrible query plans, for
example when genetic query optimizer starts
On Tue, Feb 2
Greetings,
Didn’t get your ideas with materialized CTE or a subquery with OFFSET 0
Could you please show simple example?
> 23 февр. 2021 г., в 04:33, Michael Lewis написал(а):
>
> Insert the values into a TEMPORARY TABLE, then join that to your main table?
>
> In my experience, this is very
>
> Insert the values into a TEMPORARY TABLE, then join that to your main
> table?
>
In my experience, this is very performant but needs an analyze command
after populating the temp table to ensure there are statistics so the plan
doesn't go awry. Otherwise, I'm not sure it is different from a
mat
On 2/22/21 9:00 AM, Oleksandr Voytsekhovskyy wrote:
Greetings,
We have queries with IN filters with long list of INT values
Sometimes, they running extremely slow, and I have found suggestion to use
syntax
Field IN (VALUES(1465), (1478), ...
Instead of
Field IN (1465, 1478, ...
On some cases
Wouldn't using “= any(array)” change how the query is planned? Or is the
concern just parsing the values?
On Monday, February 22, 2021, Oleksandr Voytsekhovskyy wrote:
> What is the right way to pass long INT values list to IN filter
>
Don’t.
Pass in a delimited string, then parse that string into an array and use “=
any(array)”.
This has the primary benefit of making the input a single parameter.
Greetings,
We have queries with IN filters with long list of INT values
Sometimes, they running extremely slow, and I have found suggestion to use
syntax
Field IN (VALUES(1465), (1478), ...
Instead of
Field IN (1465, 1478, ...
On some cases it helps, but on other it makes query running 1000+ ti
