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

From Alvaro Herrera
Subject Re: Proposal: scan key push down to heap [WIP]
Date
Msg-id 20161025170527.skosrgmvsilh5jjs@alvherre.pgsql
Whole thread Raw
In response to Re: Proposal: scan key push down to heap [WIP]  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Proposal: scan key push down to heap [WIP]
Re: Proposal: scan key push down to heap [WIP]
List pgsql-hackers
Dilip Kumar wrote:

> #2. Currently quals are ordered based on cost (refer
> order_qual_clauses), But once we pushdown some of the quals, then
> those quals will always be executed first. Can this create problem ?

We don't promise order of execution (which is why we can afford to sort
on cost), but I think it makes sense to keep a rough ordering based on
cost, and not let this push-down affect those ordering decisions too
much.

I think it's fine to push-down quals that are within the same order of
magnitude of the cost of a pushable condition, while keeping any other
much-costlier qual (which could otherwise be pushed down) together with
non-pushable conditions; this would sort-of guarantee within-order-of-
magnitude order of execution of quals.

Hopefully an example clarifies what I mean.  Let's suppose you have
three quals, where qual2 is non-pushable but 1 and 3 are.  cost(1)=10,
cost(2)=11, cost(3)=12.  Currently, they are executed in that order.

If you were to compare costs in the straightforward way, you would push
only 1 (because 3 is costlier than 2 which is not push-down-able).  With
fuzzy comparisons, you'd push both 1 and 3, because cost of 3 is close
enough to that of qual 2.

But if cost(3)=100 then only push qual 1, and let qual 3 be evaluated
together with 2 outside the scan node.


BTW, should we cost push-down-able quals differently, say discount some
fraction of the cost, to reflect the fact that they are cheaper to run?
However, since the decision of which ones to push down depends on the
cost, and the cost would depend on which ones we push down, it looks
rather messy.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: pg_basebackup stream xlog to tar
Next
From: Robert Haas
Date:
Subject: Re: [BUG] pg_basebackup from disconnected standby fails