summaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/tsquery_gist.c
diff options
context:
space:
mode:
authorAshutosh Bapat2011-06-28 02:35:39 +0000
committerAshutosh Bapat2011-06-28 02:35:39 +0000
commit51355d7b7c7cde644fd754ace4e21b746840e4f9 (patch)
tree38add6e2e813682ccf8cc5746b225503db45d58a /src/backend/utils/adt/tsquery_gist.c
parent1401d725b719ac2b6de45ace6e6bfd1a7413bc66 (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/utils/adt/tsquery_gist.c')
0 files changed, 0 insertions, 0 deletions