* Richard Huxton:
> I take it SELECT DISTINCT bar... shows the same problem?
SELECT bar FROM baz does *not* show the duplicate row.
> If so, can you do:
> SELECT OID,xmin,cmin,xmax,cmax,bar FROM baz
> WHERE bar =
Even if I force a complete index scan, I get xmin = 1007617 for both
rows, the
* Tom Lane:
>> According to EXPLAIN, an index scan on the bar column is used (using
>> the underlying B-tree index).
>
> Do you mean an indexscan followed immediately by a Unique node? If
> so, yeah, that would depend entirely on correct ordering of the
> indexscan output to produce distinct resu
Florian Weimer <[EMAIL PROTECTED]> writes:
> I run this innocent query
> CREATE TABLE foo AS SELECT DISTINCT bar FROM baz ORDER BY bar;
> and the resulting table contains duplicate rows. 8-(
> According to EXPLAIN, an index scan on the bar column is used (using
> the underlying B-tree index).
Do
Florian Weimer wrote:
I run this innocent query
CREATE TABLE foo AS SELECT DISTINCT bar FROM baz ORDER BY bar;
and the resulting table contains duplicate rows. 8-(
According to EXPLAIN, an index scan on the bar column is used (using
the underlying B-tree index). This is with PostgreSQL 8.1.4
I run this innocent query
CREATE TABLE foo AS SELECT DISTINCT bar FROM baz ORDER BY bar;
and the resulting table contains duplicate rows. 8-(
According to EXPLAIN, an index scan on the bar column is used (using
the underlying B-tree index). This is with PostgreSQL 8.1.4 (Debian
package 8.1.4-6)
