From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | bs <bs(at)ionicsoft(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: 7.4.xx regression |
Date: | 2004-01-26 17:00:28 |
Message-ID: | 8357.1075136428@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
bs <bs(at)ionicsoft(dot)com> writes:
> 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 !
> I think this can classified as a regression bug.
No, it can be classified as a "user forgot to vacuum or analyze"
mistake. The estimates shown in the query plan look like the defaults
for an empty table.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-01-26 18:26:54 | Re: BUG #1064: work with temporary table in plpgsql function |
Previous Message | Tom Lane | 2004-01-26 16:58:30 | Re: signal 11 |