| Lists: | pgsql-bugs |
|---|
| From: | "yuanrui" <yuanrui(at)pset(dot)suntec(dot)net> |
|---|---|
| To: | <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Wrong result of <select distinct geometry from XXX> |
| Date: | 2016-04-06 06:04:08 |
| Message-ID: | 010101d18fcaac70d0055270$@suntec.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-bugs |
Hi,
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 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.
―――――――――
袁瑞
TEL：1626
| Attachment | Content-Type | Size |
|---|---|---|
| union_test_table.zip | application/x-zip-compressed | 5.3 KB |
| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | yuanrui <yuanrui(at)pset(dot)suntec(dot)net> |
| Cc: | pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: Wrong result of <select distinct geometry from XXX> |
| Date: | 2016-04-06 20:22:24 |
| Message-ID: | CAM3SWZTngDW5zRTZvXnyGiQ_BV06sRZbxSSwmDTswx9K+91EXQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-bugs |
On Tue, Apr 5, 2016 at 11:04 PM, yuanrui <yuanrui(at)pset(dot)suntec(dot)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