Re: [GENERAL] Estimated rows question - Mailing list pgsql-hackers

From Sam Ross
Subject Re: [GENERAL] Estimated rows question
Date
Msg-id CAG+An1oBdAeBzs4GoP0hMwd86c+PCKa99YZBpybFM6QS1_Xp4w@mail.gmail.com
Whole thread Raw
Responses Re: [GENERAL] Estimated rows question  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Sep 1, 2012 at 8:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> [ sorry for slow response, but I'd not gotten time to think about this... ]
>
> Sam Ross <elliptic@gmail.com> writes:
>> I was wondering why it seems that the query planner can't "see", based
>> on the histograms, that two join-columns have a very small
>> intersection, and adjust its row estimation accordingly.
>
> The reason why not is that eqjoinsel() doesn't take any such
> consideration into account.  It's possible that it'd be a good idea
> to teach it to do so.  I'm not entirely convinced though.  It would
> add a fair amount of expense to that function, as well as adding
> some possibly shaky assumptions, and I'm not sure how often we'd
> get a usefully-better estimate in practice.  OTOH, there are a lot
> of shaky assumptions in eqjoinsel() already, and we did decide this
> was worth worrying about in mergejoin cost estimation.
>
> Do you want to try it and submit a patch for testing?
>
>                         regards, tom lane

Thanks for the answer, and sorry for the slow reply -
I'm not sure I have the necessary expertise, but I'll be happy to give
it a shot.  Is there an already-assembled library of queries that is
used to test purported improvements to the planner, or is it expected
that I come up with a convincing test-set myself?
Sam



pgsql-hackers by date:

Previous
From: Gurjeet Singh
Date:
Subject: Re: Correction to comment regarding atomicity of an operation
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Estimated rows question