Re: [SQL] index row size 2728 exceeds btree maximum, 27

Поиск
Список
Период
Сортировка
От Jaime Casanova
Тема Re: [SQL] index row size 2728 exceeds btree maximum, 27
Дата
Msg-id c2d9e70e0506020848667a6e28@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [SQL] index row size 2728 exceeds btree maximum, 27  (Richard Huxton <dev@archonet.com>)
Список pgsql-general
On 6/2/05, Richard Huxton <dev@archonet.com> wrote:
> KÖPFERL Robert wrote:
> > To me it seems that the definer of this table missed the concept index ...
> > or the concept database
> > One usually looks up data using a key, but if the whole row is the key, what
> > data shall be looked up.
>
> > So short story long: Remove data from your index.  The data column seems
> > like the data to be looked up using the key
> > (scan_id, host_ip, port_num, plugin_id, severity) or even less.
> > Postgres is able to take several indices over distinct columns into account.
> > Thus reducing the possible candidates to a hand full.
> > So several indices are also an option
>
> Actually, Dinesh didn't mention he was using this for the speed of
> lookup. He'd defined the columns as being the PRIMARY KEY, presumably
> because he feels they are/should be unique. Given that they are rows
> from a logfile, I'm not convinced this is the case.
>

If this a log he will need a timestamp field to be usefull, making
that field part of the primary key and letting the data out of the
primary has more sense to me.

--
regards,
Jaime Casanova
(DBA: DataBase Aniquilator ;)

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

Предыдущее
От: Yudie Pg
Дата:
Сообщение: Re: hpw to Count without group by
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Using pg_dump in a cron