diff options
author | Ashutosh Bapat | 2011-06-28 02:35:39 +0000 |
---|---|---|
committer | Ashutosh Bapat | 2011-06-28 02:35:39 +0000 |
commit | 51355d7b7c7cde644fd754ace4e21b746840e4f9 (patch) | |
tree | 38add6e2e813682ccf8cc5746b225503db45d58a /src/backend/access/gist/gistget.c | |
parent | 1401d725b719ac2b6de45ace6e6bfd1a7413bc66 (diff) |
The commit fixes two issues
FIRST
If for an aggregate function, collection function does not exist, we need to
collect the raw data from the data nodes and apply the transition and
finalization phases of such an aggregate on coordinator itself, i.e. such
an aggregate can not be pushed to the datanode. In PGXC, such aggregates are
indicated by invalid collection function oid in pg_aggregate.
In case of aggregates, array_agg and string_agg, the transition result type is
'internal'. These aggregates use internals structures such as ArrayBuildState
and StringInfo resp. as transition results. The clients (in this case
coordinator) can not handle transition results of 'internal' type. Hence setting
invalid collection function oid for these aggregates.
SECOND
For aggregates which use polymorphic transition types, those polymorphic types
need to be resolved before creating tuple descriptors for the remote query being
pushed to the datanode with these types of aggregates. The polymorphic
transition types are resolved during the execution phase where as the tuple
descriptor is created at planning time. Hence for now, aggregates with
polymorphic transition result types are not pushed to the datanodes.
Diffstat (limited to 'src/backend/access/gist/gistget.c')
0 files changed, 0 insertions, 0 deletions