Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
От | David Rowley |
---|---|
Тема | Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower |
Дата | |
Msg-id | CAApHDvpsgqopTiEFv5HoMkevAmxKapwxm6188U=KthZWWfAQ=w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower (Richard Guo <guofenglinux@gmail.com>) |
Ответы |
Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
|
Список | pgsql-bugs |
On Thu, 28 Sept 2023 at 16:22, Richard Guo <guofenglinux@gmail.com> wrote: > It seems that optimizing IS NULL quals is more complex than optimizing > IS NOT NULL quals. I also wonder if it's worth the trouble to optimize > IS NULL quals. I'm happy to reduce the scope of this patch. As for what to cut, I think if we're doing a subset then we should try to do that subset in a way that best leaves things open for phase 2 at some later date. In my view, it would be less surprising that this works for base quals and not join quals than if it worked with "Var IS NOT NULL" but not "Var IS NULL". I'm unsure if my view is clouded by the fact that I don't have a clear picture in my head on how this should work for join quals, however. Would it be surprising if this didn't work for join quals? My thoughts are probably not any more so than the fact that extended statistics only work for base quals and not join quals, but I'm sure other people will have different views on that. I don't feel like we should end up with exactly nothing committed from this patch solely due to scope creep. David
В списке pgsql-bugs по дате отправления: