SEO
vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
04-17-2008, 07:36 PM
| ||||
| ||||
 PGAdmin3 and inherited tables Hi, I have the same problem than described at http://www.pgadmin.org/archives/pgad...4/msg00056.php but it was not resolved then, not even correctly understood, it seems. pgAdmin keeps telling me that I should VACUUM the base table that _really_ has 0 rows: stingray:navteq=# SELECT count(*) FROM ONLY test_phonetic.match; count ------- 0 (1 row) The problem is that pgAdmin seems to include the derived tables into their count query, and then complain that the estimate is off: stingray:navteq=# SELECT count(*) FROM test_phonetic.match; count ---------- 71319833 (1 row) So the correct fix would be to include the "ONLY" keyword when pgadmin3 fetches the row count, IMHO this change should not break anything else. My version of pgAdmin3 is debianized 1.4.3-1. HTH, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFOJuYyHQIGEs7eeARA6pOAKDmDWxozUO+zTC9ubh/2UnSi4tpawCgjnUA OyUjFI6vOc/lS9TTJ5HaYJk= =F/wE -----END PGP SIGNATURE-----      |
|
04-17-2008, 07:36 PM
| ||||
| ||||
| Re: PGAdmin3 and inherited tables I've committed this fix - thanks. Regards, Dave. On 20/10/06 10:49, "Markus Schaber" <schabi@logix-tt.com> wrote: > Hi, > > I have the same problem than described at > http://www.pgadmin.org/archives/pgad...4/msg00056.php but > it was not resolved then, not even correctly understood, it seems. > > pgAdmin keeps telling me that I should VACUUM the base table that > _really_ has 0 rows: > > stingray:navteq=# SELECT count(*) FROM ONLY test_phonetic.match; > count > ------- > 0 > (1 row) > > The problem is that pgAdmin seems to include the derived tables into > their count query, and then complain that the estimate is off: > > stingray:navteq=# SELECT count(*) FROM test_phonetic.match; > count > ---------- > 71319833 > (1 row) > > So the correct fix would be to include the "ONLY" keyword when pgadmin3 > fetches the row count, IMHO this change should not break anything else. > > My version of pgAdmin3 is debianized 1.4.3-1. > > HTH, > Markus > ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match |
Linear Mode
