Toto guyoyg writes:
>> What we have here is a straightforward way to write a query versus a
>> much-less-straightforward way [...] So I'm not seeing why we should put our
>> finite development resources into optimizing the much-less-straightforward
>> way.
> Ah, I should have explained this: t
e57f1194d9f6543bc7948c16411b),
or is that expected behavior ?
(My understanding is that this wouldn't solve the performance problem of the
original query given the const array limitation but this may improve other
cases.)
Thanks again for your time!
____________
De
Matthias van de Meent writes:
> On Thu, 21 Nov 2024 at 13:03, Toto guyoyg wrote:
>> It looks like this could be improved/fixed by either/all of:
>>
>> 1. Using a hashset (or sort + binary search) for recheck (past a certain
>> array length or even always) instead of always searching linearly
>
Matthias van de Meent writes:
> On Thu, 21 Nov 2024 at 13:03, Toto guyoyg wrote:
>>
>> Offending O(n²) query:
> I disagree with the O(n^2) claims.
I think these cases actually are O(n^2). But I'm finding it hard
to care. What we have here is a straightforward way to write a
query versus a mu
On Thu, 21 Nov 2024 at 13:03, Toto guyoyg wrote:
>
> Offending O(n²) query:
I disagree with the O(n^2) claims. The number of live matched rows in
a single table's bitmap scan may be anywhere from 0 (leading to O(1)
complexity in the rescan) to 970_662_608_670 (= 226 tuples per page *
(2^32 - 1) p
Offending O(n²) query:
```sql
SELECT id FROM indexed_table WHERE indexed_value = ANY (ARRAY[1,2,...])
```
I'm not posting this on the `pgsql-performance` mailing list because this is
about fixing the issue, not working around it.
I'm not posting this on the `pgsql-bugs` mailing list because docu
