Re: Aggregate ORDER BY patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
Subject: Re: Aggregate ORDER BY patch
Date: 2009-12-14 20:08:10
Message-ID: 13078.1260821290@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Tom> and I would also expect there to be a nonzero performance hit
> Tom> from the extra TargetEntry expression nodes, even when the
> Tom> feature is not in use.

> I tested for that and couldn't reliably detect any (certainly <2%
> on count(i) on generated data, and under the circumstances I was
> testing that's not necessarily outside the error margin).

Hm. Now that I look closer I see we already have a hack to avoid
executing an extra expression node when a targetlist item is evaluated,
so the extra cost should indeed be insignificant. There would be
nonzero associated costs during planning and executor startup, but we
seldom bother optimizing for that. So nevermind...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Boley 2009-12-14 20:12:48 Re: Range types
Previous Message Tom Lane 2009-12-14 20:05:02 Re: Range types