Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation

2017-11-08 Thread Ashutosh Bapat
On Wed, Nov 8, 2017 at 3:18 AM, Tom Lane wrote: > Robert Haas writes: >> I think it would be a good idea, as Thomas says, to order the qual >> clauses at an earlier stage and then remember our decision. However, >> we have to think about whether that's

Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation

2017-11-07 Thread Tom Lane
Robert Haas writes: > I think it would be a good idea, as Thomas says, to order the qual > clauses at an earlier stage and then remember our decision. However, > we have to think about whether that's going to increase planning time > in a noticeable way. I wonder why we

Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation

2017-11-07 Thread Robert Haas
On Mon, Nov 6, 2017 at 5:19 AM, Ashutosh Bapat wrote: > IIRC, only thing that changes between plan time quals and execution > time quals is constaint folding of constant parameters. But I don't > think we change the selectivity estimates when that's done. At the >

Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation

2017-11-06 Thread Ashutosh Bapat
On Mon, Nov 6, 2017 at 10:01 AM, Thomas Munro wrote: > > This idea seems to makes intuitive sense. I see that you use > order_qual_clauses() to know what order they'll run in, so I'm > wondering if there is any reason we shouldn't do it up front and keep > it

Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation

2017-11-05 Thread Thomas Munro
On Mon, Sep 11, 2017 at 7:43 PM, Yuto Hayamizu wrote: > Suppose that there are three qual clauses in a scan node, current > postgres estimates per-tuple cost of the filter to be: >cost(A) + cost(B) + cost(C) > > And basic idea of the attached patch is: >cost(A) +

Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation

2017-09-17 Thread David Fetter
On Mon, Sep 11, 2017 at 04:43:46PM +0900, Yuto Hayamizu wrote: > Hi hackers, > > Currently, cost of a filter with multiple clauses is estimated by > summing up estimated cost of each clause. As long as a filter > consists of simple clauses and its cost is fairly small, it works > fine. However,