Re: Parallel Aggregate
От | Paul Ramsey |
---|---|
Тема | Re: Parallel Aggregate |
Дата | |
Msg-id | CACowWR19N1Fw1ijoYv57OzNyCbH5AXrDaA9W7Rqq-cWef9Xy6A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel Aggregate (Haribabu Kommi <kommi.haribabu@gmail.com>) |
Ответы |
Re: Parallel Aggregate
|
Список | pgsql-hackers |
On Thu, Dec 10, 2015 at 10:42 PM, Haribabu Kommi <kommi.haribabu@gmail.com> wrote: > > Here I attached a POC patch of parallel aggregate based on combine > aggregate patch. This patch contains the combine aggregate changes > also. This patch generates and executes the parallel aggregate plan > as discussed in earlier threads. I tried this out using PostGIS with no great success. I used a very simple aggregate for geometry union because the combine function is just the same as the transfer function for this case (I also mark ST_Area() as parallel safe, so that the planner will attempt to parallelize the query).. CREATE AGGREGATE ST_MemUnion ( basetype = geometry, sfunc = ST_Union, cfunc = ST_Union, stype = geometry ); Unfortunately attempting a test causes memory corruption and death. select riding, st_area(st_memunion(geom)) from vada group by riding; The explain looks OK: QUERY PLAN ---------------------------------------------------------------------------------------Finalize HashAggregate (cost=220629.47..240380.26rows=79 width=1189) Group Key: riding -> Gather (cost=0.00..807.49 rows=8792 width=1189) Number of Workers: 1 -> Partial HashAggregate (cost=220628.59..220629.38 rows=79 width=1189) Group Key: riding -> Parallel Seq Scan on vada (cost=0.00..806.61 rows=8792 width=1189) But the run dies. NOTICE: SRID value -32897 converted to the officially unknown SRID value 0 ERROR: Unknown geometry type: 2139062143 - Invalid type From the message it looks like geometry gets corrupted at some point, causing a read to fail on very screwed up metadata. P.
В списке pgsql-hackers по дате отправления: