From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tim Kane <tim.kane@gmail.com>
cc: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Constraint exclusion won't exclude parent table
In-reply-to: <CF9838D8.7EF3D%tim.kane@gmail.com>
References: <CF9838D8.7EF3D%tim.kane@gmail.com>
Comments: In-reply-to Tim Kane <tim.kane@gmail.com>
 message dated "Tue, 13 May 2014 21:02:16 +0100"
Date: Tue, 13 May 2014 16:24:39 -0400
Message-ID: <27718.1400012679@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Tim Kane <tim.kane@gmail.com> writes:
> So what is the append node actually doing, and why is it necessary?
> I expect that it simply does what it says, and appends the results of those
> two seq-scans.  But in reality, there isn’t a lot to do there. While I
> expect a little bit of overhead, surely it just passes the tuples straight
> through to the result node and that will be that.. No?

Yeah, it's not expected that that's going to cost much.  I am suspicious
that what you are looking at is mostly measurement overhead: during
EXPLAIN ANALYZE, each plan node has to do two gettimeofday() calls per
call, and there are lots of platforms where that is significant relative
to the actual work done per node.

You might try comparing the overall times for select count(*) from ...
rather than EXPLAIN ANALYZE for these two cases.  If those times are
much closer together than what you're getting from EXPLAIN ANALYZE,
then you've got a machine with expensive gettimeofday() and you have
to take your measurements with an appropriate quantum of salt.

			regards, tom lane


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