Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays
От | James Coleman |
---|---|
Тема | Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays |
Дата | |
Msg-id | CAAaqYe9DrqAZevT=bY+6drV_hiPSx+v14SeJPsXmWcBMHbaLrw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays (David Rowley <dgrowleyml@gmail.com>) |
Список | pgsql-hackers |
On Fri, May 7, 2021 at 8:38 PM David Rowley <dgrowleyml@gmail.com> wrote: > > It's important to think of other cases, I just don't think there's any > need to do anything for that one. Remember that we have the > restriction of requiring a set of Consts, so for that case to be met, > someone would have to write something like: col = > ALL('{1,1,1,1,1,1,1,1}'::int[]); I think if anyone comes along > complaining that a query containing that is not as fast as they'd like > then we might tell them that they should just use: col = 1. A sanity > checkup might not go amiss either. I wasn't concerned with trying to optimize this case (I don't think we can anyway, at least not without adding new work, like de-duplicating the array first). Though I do hope that someday I'll/we'll get around to getting the stable subexpressions caching patch finished, and then this will be able to work for more than constant arrays. I just wanted to confirm we'd thought through the cases we can't handle to ensure we're not accidentally covering them. James
В списке pgsql-hackers по дате отправления: