Re: Aggregate ORDER BY patch
От | Tom Lane |
---|---|
Тема | Re: Aggregate ORDER BY patch |
Дата | |
Msg-id | 13078.1260821290@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Aggregate ORDER BY patch (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Список | pgsql-hackers |
Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > "Tom" == Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: