Thread: PGAdmin3 and inherited tables

Hi,

I have the same problem than described at
http://www.pgadmin.org/archives/pgadmin-support/2006-04/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

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/pgadmin-support/2006-04/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
>