From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org, Mark Wong <markwkm(at)gmail(dot)com> |
Subject: | Re: nested loop semijoin estimates |
Date: | 2015-06-02 15:34:17 |
Message-ID: | 556DCCF9.9030505@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 06/02/15 16:37, Tom Lane wrote:
> Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
>> OK, so I did the testing today - with TPC-H and TPC-DS benchmarks. The
>> results are good, IMHO.
>
> I'm a bit disturbed by that, because AFAICS from the plans, these
> queries did not involve any semi or anti joins, which should mean
> that the patch would not have changed the planner's behavior. You
> were using the second patch as-posted, right, without further hacking
> on compare_path_costs_fuzzily?
Yes, no additional changes.
> It's possible that the change was due to random variation in ANALYZE
> statistics, in which case it was just luck.
I don't think so. I simply loaded the data, ran ANALYZE, and then simply
started either master or patched master. There should be no difference
in statistics, I believe. Also, the plans contain pretty much the same
row counts, but the costs differ.
For example look at the 'cs_ui' CTE, right at the beginning of the
analyze logs. The row counts are exactly the same, but the costs are
different. And it's not using semijoins or not nested loops ...
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-06-02 15:36:56 | Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 |
Previous Message | Robert Haas | 2015-06-02 15:29:24 | Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 |