Re: *very* inefficient choice made by the planner (regarding

Поиск
Список
Период
Сортировка
От Stephan Szabo
Тема Re: *very* inefficient choice made by the planner (regarding
Дата
Msg-id 20040618082006.N86299@megazone.bigpanda.com
обсуждение исходный текст
Ответ на Re: *very* inefficient choice made by the planner (regarding  (SZUCS Gábor <surrano@mailbox.hu>)
Список pgsql-performance
On Fri, 18 Jun 2004, [iso-8859-1] SZUCS Gábor wrote:

> Dear Gurus,
>
> ----- Original Message -----
> From: "Stephan Szabo" <sszabo@megazone.bigpanda.com>
> Sent: Thursday, June 10, 2004 7:14 PM
>
>
> >
> > On Thu, 10 Jun 2004, Stephan Szabo wrote:
> >
> > >
> > > On Thu, 10 Jun 2004, Jean-Luc Lachance wrote:
> > >
> > > > I agree, but it should be a simple rewrite. No?
> > >
> > > It's NULLs inside the subselect that are the issue.
> > >
> > > select 1 in (select a from foo)
> > > select exists ( select 1 from foo where a=1)
>
> Just a dumb try :)
>
>   SELECT (exists(select 1 from foo where a isnull) AND NULL)
>        OR exists(select 1 from foo where a=1)
>
> AFAIK this returns
> * NULL if (NULL in foo.a) and (1 not in foo.a)
> * (1 in foo.a) otherwise.
>
> The weakness is the doubled exists clause. I'm sure it makes most cases at
> least doubtful...

Well, once you take into account the lhs being potentially null
 lhe in (select rhe from foo) is something like:

case when lhe is null then
 not exists(select 1 from foo limit 1) or null
else
 (exists(select 1 from foo where rhe is null) and null)
 or exists(select 1 from foo where rhe=lhe)
end

I think the real win occurs for where clause cases if it can pull up the
exists that references lhe so that it doesn't try to evaluate it on every
row and that's unlikely to occur in something like the above.

В списке pgsql-performance по дате отправления:

Предыдущее
От: pginfo
Дата:
Сообщение: Re: Major differences between oracle and postgres performance
Следующее
От: Gary Cowell
Дата:
Сообщение: Re: Major differences between oracle and postgres performance - what can I do ?