Обсуждение: Wrong result of
Hi, Sorry to bother.=20 I have encountered the following problem, please help me. The attached file is a backup file of two geometries, the table name is <temp_union_test>, the column of geometry is <the_geom>. when I execute < select distinct the_geom from temp_union_test >, there = is only one row returned, but actually, the two geometries is totally different. I have tried this execution on PostgreSql 9.0 and PostgreSql 9.5, the results is always the same. Would you help me to solve this problem? If you have any concern about it, I would be very appreciate it. Thank you. =A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA =D4=AC=C8=F0 TEL=A3=BA1626
On Tue, Apr 5, 2016 at 11:04 PM, yuanrui <yuanrui@pset.suntec.net> wrote: > > Sorry to bother. > I have encountered the following problem, please help me. > > The attached file is a backup file of two geometries, the table name is > <temp_union_test>, the column of geometry is <the_geom>. > when I execute < select distinct the_geom from temp_union_test >, there is > only one row returned, but actually, the two geometries is totally > different. I think this might have something to do with weird legacy issues that PostGIS has: http://www.postgresql.org/message-id/etPan.559d8d4b.7c83e458.e975@Crane.local This is basically a mistake that PostGIS made, but is now stuck with. What does EXPLAIN show the plan as? Do you get a difference answer when the plan is a hashAggregate instead of a unique + sort? You can test this using "set enable_hashagg = off", or maybe "set enable_sort = off" depending on the details (could be an index scan instead of a sort for a unique node). -- Peter Geoghegan