Re: Indexes generated for primary key are not show

Andreas Pflug wrote:

> We deliberately do *not* support anything that psql does. psql bears a
> lot of ancient stuff, since it has developed from very early pgsql
> versions. psql works one level below pgAdmin3, showing all the raw stuff
> regardless whether it's useful nowadays or not, e.g. constraint
> triggers. pgAdmin shows the objects in a way that's suitable for pgsql
> 7.3 and up, suppressing system stuff you might have become used to from
> <= 7.2 times. To work with pgAdmin3, your database should be 7.3 or up
> in every way, i.e. if updated from earlier version adddepend should have
> been executed.
I do not suggest PgAdmin to become 'psql with GUI'. They are different
applications. But in some questionable issues I would suggest to use
psql as a reference, because it constains almost everything that is
needed for everyday work.
In case I explained PgAdmin does not provide enough information for
work, so I need to use another tool (psql). I am speaking only about
making PgAdmin fully sufficient for all the work which may be done
through database support.
Let me introduce 2 scenarios which explains what I mean.
Prologue is the same in both - creating table (I write SQL, but when I
stepped into the bug, I was doing the same with PgAdmin GUI).
CREATE TABLE test (
a int,
b int,
PRIMARY KEY(a)
);
Now implicit index on column a is created, but it is not shown by PgAdmin.
I populate table with some data, use VACUUM ANALYZE to compute
statictics. Then I write query something like that
SELECT sum(b) WHERE a BETWEEN 1 AND 5;
Then 2 possible continuations.
1. I run EXPLAIN on that query, see index scan and begin to search for a
bug (I don't see index). Possible places for bug: planner (decides to
use index which is not present), PgAdmin (erraticaly parsing output),
PgAdmin (not showing index). The last is the true, but to realize it I
had to check with psql. Therefore - PgAdmin is not enough for
understanding what is happening.
2. I try to optimize query and create index with PgAdmin. Now I have 2
almost equivalent indexes wasting space and time. If planner decides to
use index created when creating primary key, we will come to scenario 1.
If it uses manually created index, I will not see that I have
unneseccary index which consumes disk space and processor time while
inserting new rows.

I got that it is quite a hard work to make PgAdmin show indexes from
primary key while not breaking other things. But I think it would be
nice if it falls into TODO list (as a distant entry or simply as a
suggestion).

Thanks.

--
Constatin Stefanov