On Mon, Mar 7, 2016 at 4:39 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Haribabu Kommi <kommi.harib...@gmail.com> writes: >> 2. Temporary fix for float aggregate types in _equalAggref because of >> a change in aggtype to trans type, otherwise the parallel aggregation >> plan failure in set_plan_references. whenever the aggtype is not matched, >> it verifies with the trans type also. > > That is a completely unacceptable kluge. Quite aside from being ugly as > sin, it probably breaks more things than it fixes, first because it breaks > the fundamental semantics of equal() across the board, and second because > it puts catalog lookups into equal(), which *will* cause problems. You > can not expect that this will get committed, not even as a "temporary fix".
I am not able to find a better solution to handle this problem, i will provide the details of the problem and why I did the change, so if you can provide some point where to look into, that would be helpful. In parallel aggregate, as the aggregate operation is divided into two steps such as finalize and partial aggregate. The partial aggregate is executed in the worker and returns the results of transition data which is of type aggtranstype. This can work fine even if we don't change the targetlist aggref return type from aggtype to aggtranstype for aggregates whose aggtype is a variable length data type. The output slot that is generated with variable length type, so even if we send the aggtrantype data that is also a variable length, this can work. But when it comes to the float aggregates, the aggtype is a fixed length and aggtranstype is a variable length data type. so if we try to change the aggtype of a aggref in set_plan_references function with aggtrantype only the partial aggregate targetlist is getting changed, because the set_plan_references works from top of the plan. To avoid this problem, I changed the target list type during the partial aggregate path generation itself and that leads to failure in _equalAggref function in set_plan_references. Because of which I put the temporary fix. Do you have any point in handling this problem? Regards, Hari Babu Fujitsu Australia -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers