From: | pgsql-bugs(at)postgresql(dot)org |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Optimalisation options change query results |
Date: | 2001-04-27 09:49:29 |
Message-ID: | 200104270949.f3R9nTf11241@hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Marcin Zukowski (eru(at)mimuw(dot)edu(dot)pl) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
Optimalisation options change query results
Long Description
I had a problem with retrieving data when some of the multi-column index fields were NULL - it was always at the end. Since I wanted null fields be treated either 'bigger than everything' or 'smaller than everything' I tried to use some optimalisation options to force sorting method.
And it worked.
And I think it should not :)
I have tried it on:
PostgreSQL 7.0.3 on i586-pc-linux-gnu, compiled by gcc egcs-2.91.66
If you run example code you will see, that after changing some query optimalisation switches the result CHANGED.
My conclusion: when sorting data null values are always set at the end, so during retrieving in DESC order using index they are first.
When making Sort during query execution, they are always last.
Sample Code
DROP TABLE NUTKI ;
CREATE TABLE NUTKI (
ID INT4 PRIMARY KEY,
VAL INT4
);
CREATE INDEX NUTKI_VAL ON NUTKI(VAL);
INSERT INTO NUTKI VALUES(1,1);
INSERT INTO NUTKI VALUES(2,null);
SET ENABLE_INDEXSCAN TO OFF ;
SET ENABLE_SEQSCAN TO ON ;
SET ENABLE_SORT TO ON ;
EXPLAIN SELECT * FROM NUTKI ORDER BY VAL DESC ;
SELECT * FROM NUTKI ORDER BY VAL DESC ;
SET ENABLE_INDEXSCAN TO ON ;
SET ENABLE_SEQSCAN TO OFF ;
SET ENABLE_SORT TO OFF ;
EXPLAIN SELECT * FROM NUTKI ORDER BY VAL DESC ;
SELECT * FROM NUTKI ORDER BY VAL DESC ;
No file was uploaded with this report
From | Date | Subject | |
---|---|---|---|
Next Message | pgsql-bugs | 2001-04-27 11:29:33 | Input/Output of byte[]-Fields with 'FF' values in LargeObject with JDBC |
Previous Message | Chris Storah | 2001-04-27 07:58:43 | 7.1 euro-style dates insert error |