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
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 |