Le 29/10/2010 14:46, Guillaume Lelarge a écrit : > Le 29/10/2010 13:52, Rob Richardson a écrit : >> A customer was reviewing the database that supports the application we >> have provided. One of the tables is very simple, but has over 16 >> million records. Here is the table's definition: >> >> CREATE TABLE feedback >> ( >> charge integer, >> elapsed_time integer, -- number of elapsed minutes since data began >> recording >> tag_type character varying(24), -- Description of tag being recorded >> tag_value real, -- value of tag being recorded >> status smallint, -- PLC Status, recorded with Control PV only >> stack integer, -- Not used >> heating smallint DEFAULT 0, -- 1 for heating, 0 for cooling >> cooling smallint DEFAULT 0 -- not used >> ) >> >> As you see, there is no primary key. There is a single index, as >> follows: >> >> CREATE INDEX feedback_charge_idx >> ON feedback >> USING btree >> (charge); >> >> In PGAdmin, the customer selected this table and clicked the grid on the >> toolbar, asking for all of the records in the table. After twenty >> minutes, a message box appeared saying that an unhandled exception had >> happened. There was no explanation of what the exception was. The >> database log does not contain any information about it. The PGAdmin >> display did show a number of records, leading me to believe that the >> error happened in PGAdmin rather than anywhere in PostGres. >> >> Can anyone explain what is happening? >> > > Definitely not an error in PostgreSQL. More related to pgAdmin. > >> The customer is using PostgreSQL 8.4.5 (we just updated them within the >> last few days) and PGAdmin 1.10.5 on a Windows Server 2003 box. >> >> I see PGAdmin is now up to 1.12.1. I suppose the first thing I should >> do is update their PGAdmin. >> > > Won't do anything if your customer still wants to look at 16 million rows. > > The only thing we could probably do on the coding side is looking at the > estimated number of rows and displays a warning message telling: "Hey > dude, you're trying to look at around 16 million rows. That can't work. > You would be very well advised to cancel.", but still allows the user to > bypass this check (if the estimated number of rows is wrong). > I added a ticket on this (http://code.pgadmin.org/trac/ticket/273) so that we can work on it at a later time. -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
