7.4.xx regression
| От | bs | 
|---|---|
| Тема | 7.4.xx regression | 
| Дата | |
| Msg-id | 400E4B91.1060402@ionicsoft.com обсуждение исходный текст | 
| Ответы | Re: 7.4.xx regression | 
| Список | pgsql-bugs | 
I have the following tables and indexes
CREATE TABLE cddb
(
    id integer PRIMARY KEY,
    /* artist name */
    name text,
    /* disk title */
    title text,
    /* the type of the artist group, person, orchestra*/
    type smallint,
    /* the creation date */
    created integer
);
CREATE INDEX cddb1 on cddb(title);
CREATE INDEX cddb2 on cddb(name);
CREATE TABLE cddbentry
(
    id integer PRIMARY KEY,
    diskid text,
    entry integer REFERENCES cddb
);
CREATE INDEX cddbentry1 on cddbentry (diskid);
CREATE INDEX cddbentry2 on cddbentry (entry);
I am using the following query:
select cddb.* from cddb,cddbentry where cddbentry.diskid = 'toto' and
cddbentry.entry = cddb.id;
On version 7.3.4 it produces this query plan
Nested Loop  (cost=0.00..41.25 rows=5 width=78)
   ->  Index Scan using cddbentry1 on cddbentry  (cost=0.00..17.07
rows=5 width=4)
         Index Cond: (diskid = 'toto'::text)
   ->  Index Scan using cddb_pkey on cddb  (cost=0.00..4.82 rows=1 width=74)
         Index Cond: ("outer".entry = cddb.id)
I have upgraded to version 7.4.0 (compiling the software and migrating
the database using dump/restore)
Now the following plan is produced
Hash Join  (cost=17.08..42.15 rows=7 width=74)
   Hash Cond: ("outer".id = "inner".entry)
   ->  Seq Scan on cddb  (cost=0.00..20.00 rows=1000 width=74)
   ->  Hash  (cost=17.07..17.07 rows=6 width=4)
         ->  Index Scan using cddbentry1 on cddbentry  (cost=0.00..17.07
rows=6 width=4)
               Index Cond: (diskid = 'toto'::text)
which result in a VERY much slower query as the cddb table has more than
1 million entry....  and there is at most one entry in cddbentry
which matches the diskid !
The workaround is to disable the hash join capability using set
enable_hashjoin to false;  resulting in the same query plan as in 7.3.x.
I think this can classified as a regression bug.
N.B: The cost value may be wrong, because to be able to send you this
email, they have been produced on empty tables; but
I can guarantee you they are the same on the full loaded database.
Hope this help to improve this great product
Bernard SNYERS
		
	В списке pgsql-bugs по дате отправления: