Re: equivalent queries lead to different query plans for self-joins with group by?

Поиск
Список
Период
Сортировка
От Ben
Тема Re: equivalent queries lead to different query plans for self-joins with group by?
Дата
Msg-id 5E705CB3-DF3D-4804-8F87-984D2041C9AC@gmail.com
обсуждение исходный текст
Ответ на Re: equivalent queries lead to different query plans for self-joins with group by?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
appreciate the instant response.

> Well, arguably it's not doing the right thing either way --- you'd sort
> of like the inequalities to get pushed down into both of the join
> inputs, not just one of them.  PG doesn't make that deduction though;
> it can make such inferences for equalities, but inequalities are not
> optimized as much.

in my work i have replaced the query with a sql function + window :

create or replace function bar(timestamp, timestamp) returns setof foo
language 'sql' as $$
  select ts,
         id,
         val -
         (avg(val) over (partition by ts)) as val
  from foo
  where ts > $1
  and ts < $2
$$;

i was forced to use a sql function as opposed to a view because the query planner was unable to push down restrictions
onts inside the view subquery, which i've manually done in the function.  indeed, 

explain select ts, id, val - (avg(val) over (partition by ts)) as val from foo where ts > '2009-10-20' and ts <
'2009-10-21';

and

explain select * from (select ts, id, val - (avg(val) over (partition by ts)) as val from foo) as f where ts >
'2009-10-20'and ts < '2009-10-21'; 

give different answers, despite being equivalent, but i understand it is hard to push things into subqueries in
general. in this case it is only legal because we partition by ts. 

thanks again for the explanations!

best, ben


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: equivalent queries lead to different query plans for self-joins with group by?
Следующее
От: Jon Nelson
Дата:
Сообщение: Re: postmaster consuming /lots/ of memory with hash aggregate. why?