Re: Proposal: scan key push down to heap [WIP] - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Proposal: scan key push down to heap [WIP]
Date
Msg-id CAFiTN-szrGfkELW0g_SxJUoTYrrcryzziNvJio7ZyQQcYR9iNw@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: scan key push down to heap [WIP]  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Proposal: scan key push down to heap [WIP]  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Amit Langote
Date:
Subject: Typo in foreign.h
Next
From: Tatsuo Ishii
Date:
Subject: Re: parallel.sgml