Jimmy Mäkelä wrote:
> I found that Postgres isn't behaving like I thought when using a
> unique index in
> combination with NULL-values...
> Is this a bug or specified in the SQL-standard? If its a bug, is it
> fixed in a
> recent version? We are using 7.2.3
>
> This is the results I got:
>
> intranet=# create table foo (a varchar(10), b varchar(10));
> CREATE
> intranet=# create unique index foo_idx on foo using btree(a, b);
> CREATE
> intranet=# insert into "foo" (a, b) values ('apa', 'banan');
> INSERT 26229704 1
> intranet=# insert into "foo" (a, b) values ('apa', 'banan');
> ERROR: Cannot insert a duplicate key into unique index foo_idx
> intranet=# insert into "foo" (a, b) values ('apa', null);
> INSERT 26229706 1
> intranet=# insert into "foo" (a, b) values ('apa', null);
> INSERT 26229707 1
I'm not sure unique index works properly for null values. I can't
explain, why. Maybe it comes from SQL standard - null i a special value
and can't be compared using default operators to other non null values:
1>null =null
1<null =null
1=null =null
>
>
> And another completely unrelated question... I have got a table with a
> composite
> index on A andBb and an index on A
> which I query with something like this:
>
> SELECT * FROM "table"
> WHERE (a = 1 OR a = 2 OR a = 3) AND b > 1232132 AND b < 123123123213123
>
> Postgres then chooses to use the index for A three times, which is
> really slow
> on my table...
> Then I rewrote the query like:
>
> SELECT * FROM "table"
> WHERE a = 1 AND b > 1232132 AND b < 123123123213123
> UNION SELECT * FROM "table"
> WHERE a = 2 AND b > 1232132 AND b < 123123123213123
> UNION SELECT * FROM "table"
> WHERE a = 3 AND b > 1232132 AND b < 123123123213123
Try to rewrite your query to show postgres how to use index on AB:
SELECT * FROM "table"
WHERE
(a = 1 AND b > 1232132 AND b < 123123123213123) or
(a = 2 AND b > 1232132 AND b < 123123123213123) or
(a = 3 AND b > 1232132 AND b < 123123123213123);
Regards,
Tomasz Myrta
