Re: [gnome-db] postgresql provider performance

Mark Johnson wrote:
Vivien Malerba wrote:
On Jan 30, 2008 4:04 PM, Mark Johnson <mrj001 shaw ca> wrote:
But what information does it provide?  Here is a sample session from psql:
issue001_db=# \d+ slots
                         Table "public.slots"
      Column       |          Type          | Modifiers | Description
 slot_id           | integer                | not null  |
 obj_guid          | character(32)          | not null  |
 name              | character varying(500) | not null  |
 slot_type         | integer                | not null  |
 int64_val         | bigint                 |           |
 string_val        | character varying(500) |           |
 double_val        | bigint                 |           |
 timespec_val      | date                   |           |
 guid_val          | character(32)          |           |
 numeric_val_num   | bigint                 |           |
 numeric_val_denom | bigint                 |           |
    "slots_pkey" PRIMARY KEY, btree (slot_id)
Has OIDs: no

issue001_db=# SELECT 1 FROM pg_catalog.pg_class c,
pg_catalog.pg_constraint c2, pg_catalog.pg_attribute a WHERE c.relname =
'slots' AND c.oid = c2.conrelid and a.attrelid = c.oid and c2.contype =
'P' and c2.conkey[1] = a.attnum and a.attname = 'slot_id';
(0 rows)

There is not a single row returned by this query.  'slot-id' is the
primary key column, which seems to be something this query might be
looking for.  Does this possibly behave differently in an older version
of PostgreSQL?  I am using 8.2.6.
I believe the information is in the existence of a row returned or no.
The c2.contype='P' test checks if the column is a primary key. This alternates with checking the columns for a unique key ('u'). However, the query is returning zero rows regardless of the presence or absence of a primary or unique key. In the above instance, the column is a primary key as shown by the \d+ command. When I tried columns that are not primary keys, they return the same results. I believe, therefore, that there is a problem with this query.
Found the problem. See bug513543:

The 'P' should be 'p'.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]