Date: Sun, 8 Jun 2014 08:53:27 -0700 (PDT)
From: David G Johnston <david.g.johnston@gmail.com>
To: pgsql-performance@postgresql.org
Message-ID: <1402242807947-5806450.post@n5.nabble.com>
In-Reply-To: <1402235935505-5806445.post@n5.nabble.com>
References: <4D00B4DE.3030508@xgs-france.com>
 <AANLkTikoRUG9qJv0wZVq-n_RKDX0kOqve3PTKjPwc_MZ@mail.gmail.com>
 <AANLkTinC0ZcS1N54T-jmpj3VPWVnW15apmWVCKucgnD0@mail.gmail.com>
 <1402235935505-5806445.post@n5.nabble.com>
Subject: Re: UNION and bad performance
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

pinker wrote
>>> rhaas=# explain select a from generate_series(1,100) a union select a
>>> from generate_series(1,100) a;
>>>                                      QUERY PLAN
>>> --------------------------------------------------------------------------------------
>>> HashAggregate  (cost=45.00..65.00 rows=2000 width=4)
>>>   ->  Append  (cost=0.00..40.00 rows=2000 width=4)
> 
> 
> Why in this case the estimated number of rows is 2000? Is it standard
> planner behavior?

http://www.postgresql.org/docs/9.1/static/sql-createfunction.html

Note the "ROWS" property.

Functions are black-boxes to the planner so it has no means of estimating a
row count.  So a set returning function uses 1,000 and all others use 1.

Determining "COST" is similarly problematic.

David J.


--
View this message in context: http://postgresql.1045698.n5.nabble.com/UNION-and-bad-performance-tp3301375p5806450.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance