The following statement is running on a geological timescale (i.e., very slowly) in a version 11 database:

DELETE TOP 1000 FROM yyy ORDER BY pk ASC;

The table is quite small, but is subject to "high throughput" processing (many inserts, many deletes). The schema look OK in Foxhound except for one thing; a huge and wildly bogus "1.1G index" space value which is based on SYSPHYSIDX.leaf_page_count:

CREATE TABLE xxx.yyy ( -- 6,751 rows, 1.1G total = 18.7M table + 8k ext + 1.1G index, 175,190 bytes per row
   pk                  /* PK        */ INTEGER NOT NULL DEFAULT autoincrement,
   WorkstationName                     CHAR ( 30 ) NULL,
   SiteID                              CHAR ( 16 ) NULL,
   PatientID                           CHAR ( 16 ) NULL,
   PatLastName                         CHAR ( 20 ) NULL,
   PatFirstName                        CHAR ( 20 ) NULL,
   PatMiddleName                       CHAR ( 20 ) NULL,
   Sex                                 CHAR ( 1 ) NULL,
   BirthDate                           TIMESTAMP NULL,
   ExamID                              CHAR ( 8 ) NULL,
   Modality                            CHAR ( 5 ) NULL,
   ExamCode                            CHAR ( 32 ) NULL,
   AcquSiteID                          CHAR ( 16 ) NULL,
   ExamDate                            TIMESTAMP NULL,
   PlacerOrderNum                      CHAR ( 64 ) NULL,
   IPAddress                           CHAR ( 130 ) NULL,
   StationID                           CHAR ( 16 ) NULL,
   UserID                              CHAR ( 64 ) NULL,
   UserLastName                        CHAR ( 20 ) NULL,
   UserFirstName                       CHAR ( 64 ) NULL,
   AccessTime                          TIMESTAMP NULL,
   ActivityCode                        INTEGER NULL,
   AlertFlag                           INTEGER NULL,
   Comments                            LONG VARCHAR NULL,
   PatientIDIssuer                     CHAR ( 64 ) NULL,
   FillerOrderNum                      CHAR ( 64 ) NULL,
   UserAcctLoginID                     CHAR ( 32 ) NULL,
   RoleName                            CHAR ( 64 ) NULL,
   Client                              INTEGER NULL,
   ApplicationName                     CHAR ( 32 ) NULL,
   DatabaseUserName                    CHAR ( 32 ) NULL,
   OSUserName                          CHAR ( 32 ) NULL,
   DBAIndicator                        INTEGER NULL,
   ResourceIndicator                   INTEGER NULL,
   AuditIndicator                      INTEGER NULL,
   CONSTRAINT ASA356 PRIMARY KEY ( -- 1.1G
      pk )
);

Here's where the numbers come from in Foxhound...
rows   SYSTABLE.count
table  SYSTABLE.table_page_count
ext    SYSTABLE.ext_page_count 
index  SYSPHYSIDX.leaf_page_count for version 10 to 16, SYSATTRIBUTE.attribute_value for version 9

Clearly, it is logically impossible for a primary key index containing 6,751 INTEGER values to take up 1.1G... but if true physically that might explain why a DELETE TOP ORDER BY might run rather [cough] slowly.

Is this a symptom of corruption, or simply a table in dire need of reorganization?

(FWIW the "175,190 bytes per row" is a result of the "1.1G index" space, not the "8k ext" space used by the presumably-almost-always-empty LONG VARCHAR column.)