Still investigating, but ... CREATE INDEX problem in v6.5.x ...

Поиск
Список
Период
Сортировка
От The Hermit Hacker
Тема Still investigating, but ... CREATE INDEX problem in v6.5.x ...
Дата
Msg-id Pine.BSF.4.21.0001061428260.18498-100000@thelab.hub.org
обсуждение исходный текст
Список pgsql-hackers
Working on a database that has a table that looks like:

Table    = daily
+----------------------------------+----------------------------------+-------+
|              Field               |              Type                | Length|
+----------------------------------+----------------------------------+-------+
| n                                | int4                             |     4 |
| date                             | date                             |     4 |
| cookie                           | char()                           |     1 |
| id                               | text                             |   var |
+----------------------------------+----------------------------------+-------+
Indices:  zdaily_cookie         zdaily_date_n

Want to create a third index on id, so run:

CREATE INDEX zdaily_id ON daily (id);

Eventually, the CREATE INDEX just crashes...

daily is big:

-rw-------   1 postgres postgres 979255296 Jan  6 02:04 daily

But, the other two indices are fine:

-rw-------   1 postgres postgres 241123328 Jan  6 02:26 zdaily_date_n
-rw-------   1 postgres postgres 229220352 Jan  6 02:13 zdaily_cookie

We're currently using v6.5.1, since it used to work there, but have tried
with with v6.5.3 also, same results...

I've thought about out of disk space problems, but the file system that
its on has over 2gig free on it, and the table is <1gig to start with...

I'm running it again right now, after running a vacuum on it, just in case
that picked up something, but the vacuum looks clean:

webusers=> vacuum verbose daily;
NOTICE:  --Relation daily--
NOTICE:  Pages 119538: Changed 0, Reapped 0, Empty 0, New 0; Tup 11358404: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0,
MinLen53, MaxLen 3959; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. Elapsed 9/2 sec.
 
NOTICE:  Index zdaily_date_n: Pages 29434; Tuples 11358404. Elapsed 2/18 sec.
NOTICE:  Index zdaily_cookie: Pages 27981; Tuples 11358404. Elapsed 3/18 sec.

The index is being created on disk, but doesn't grow beyond the 16k shown
here:

ls -lt *daily*
-rw-------   1 postgres postgres    16384 Jan  6 13:32 zdaily_id
-rw-------   1 postgres postgres 241123328 Jan  6 02:26 zdaily_date_n
-rw-------   1 postgres postgres 229220352 Jan  6 02:13 zdaily_cookie
-rw-------   1 postgres postgres 979255296 Jan  6 02:04 daily

We have no "verbose" mode for a create index, do we?  Something that would
narrow down a record whose 'id' field has bad data in it?

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
Следующее
От: The Hermit Hacker
Дата:
Сообщение: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL