Re: Proposal: scan key push down to heap [WIP]

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: Proposal: scan key push down to heap [WIP]
Дата
Msg-id CAFiTN-szrGfkELW0g_SxJUoTYrrcryzziNvJio7ZyQQcYR9iNw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal: scan key push down to heap [WIP]  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Proposal: scan key push down to heap [WIP]  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Oct 13, 2016 at 6:05 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> I seriously doubt that this should EVER be supported for anything
> other than "var op const", and even then only for very simple
> operators.
Yes, with existing key push down infrastructure only "var op const",
but If we extend that I think we can cover many other simple
expressions, i.e

Unary Operator : ISNULL, NOTNULL
Other Simple expression : "Var op Const", "Var op Var", "Var op
SimpleExpr(Var, Const)" ..

We can not push down function expression because we can not guarantee
that they are safe, but can we pushdown inbuilt functions ? (I think
we can identify their safety based on their data type, but I am not
too sure about this point).
 For example, texteq() is probably too complicated, because
> it might de-TOAST, and that might involve doing a LOT of work while
> holding the buffer content lock.  But int4eq() would be OK.
>
> Part of the trick if we want to make this work is going to be figuring
> out how we'll identify which operators are safe.
Yes, I agree that's the difficult part. Can't we process full qual
list and decide decide the operator are safe or not based on their
datatype ?

What I mean to say is instead of checking safety of each operator like
texteq(), text_le()...
we can directly discard any operator involving such kind of data types.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Typo in foreign.h
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: parallel.sgml