Florian Pflug <f...@phlo.org> writes: > My argument is that is costs us more complexity to duplicate everything > for the invertible case, *and* the result seems less flexible - not > from the POV of aggregate implementations, but from the POV of future > extensions.
[ shrug... ] You can argue against any feature whatsoever by claiming that it might possibly conflict with something we would wish to do sometime in the future. I think you need to have a much more concrete argument about specific issues this will cause in order to be convincing. For all we know about ROLLUP/CUBE implementation issues right now, doing this feature with separate implementations might make that easier not harder. (I note that the crux of my complaint right now is that we're asking sfuncs to serve two masters --- how's it going to be better when they have to serve three or four?) > As for evidence - have you looked at the patch I posted? I'd be very > interested to know if it removes the performance differences you saw. (1) You can't really prove the absence of a performance issue by showing that one specific aggregate doesn't have an issue. (2) These results (mine as well as yours) seem mighty platform-dependent, so the fact you don't see an issue doesn't mean someone else won't. (3) A new FunctionCallInfoData field just for this? Surely not. There's got to be a distributed cost to that (although I notice you didn't bother initializing the field most places, which is cheating). Now point 3 could be addressed by doing the signaling in some other way with the existing context field. But it's still the case that you're trying to band-aid a bad design. There's no good reason to make the sfunc do extra work to be invertible in contexts where we know, with certainty, that that work is useless. Especially not when we know that even a few instructions of extra work can be performance-significant. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers