Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?

Поиск
Список
Период
Сортировка
От Finnerty, Jim
Тема Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?
Дата
Msg-id C83D5E20-0639-40AE-AF36-42AEC6F9A702@amazon.com
обсуждение исходный текст
Ответ на Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?  (Andy Fan <zhihui.fan1213@gmail.com>)
Список pgsql-hackers
Дерево обсуждения

 

 

So I think knowing what bad it is to have this feature is the key point to discussion now. 

 

 

> While I've only read your description of the patch not the patch itself, 

 

This comment applies to me also. 

 

Is the join selectivity properly calculated in all cases, e.g. in the n:m join case in particular, or in general when you’re not joining to a unique key? (this would be the usual situation here, since it adds a range qual to a join qual)

 

>> Furthermore, there are some cases involving parameterized paths where
>> enforcing the inequality multiple times is definitely bad

 

  • This has been done by committing 4. 

 

What remaining cases are there where the qual is evaluated redundantly?

 

  • Anyone still have interest in this?  Or is a better solution really possible?  

Or is the current method  too bad to rescue? 

 

As you’ve shown, this can potentially be very important, though I don’t think you’ll often see equijoins with an additional range restriction on the join keys.  When it happens, though, it could be especially important for joins to partitioned tables with many remote fdw partitions when the join can’t be pushed down to the remote server.

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Nonrandom scanned_pages distorts pg_class.reltuples set by VACUUM
Следующее
От: Tomas Vondra
Дата:
Сообщение: Isn't gist_page_items broken for opclasses with compress methods?