Re: Composite Index question

Поиск
Список
Период
Сортировка
От Rob Sargent
Тема Re: Composite Index question
Дата
Msg-id 4CBF8501.2000007@gmail.com
обсуждение исходный текст
Ответ на Re: Composite Index question  (DM <dm.aeqa@gmail.com>)
Ответы Re: Composite Index question  (DM <dm.aeqa@gmail.com>)
Список pgsql-general
If you can think of one benefit from having the redundant index then by
all means keep it.  It certainly eludes me.  Seems to me, removing an
un-necessary index on a huge table can only be a good thing.

On 10/20/2010 06:02 PM, DM wrote:
> Its a huge table in production, i dont want to take any risk.
>
> I can simulate and test this but i was to checking to see If any one
> knows off hand about this.
>
>
>
> I can simulate it but
> On Wed, Oct 20, 2010 at 4:57 PM, Rob Sargent <robjsargent@gmail.com
> <mailto:robjsargent@gmail.com>> wrote:
>
>     Hm. Run some queries; drop the second version of the index definition;
>     re-run the same queries; report to the group.  The redundant index isn't
>     helping, that much is certain.
>
>     On 10/20/2010 05:43 PM, DM wrote:
>     > Composite Index question:
>     >
>     > I have composite index on 3 columns on a table, by mistake the
>     composite
>     > index was created twice on the table.
>     >
>     > Will there any performance issues on this table because of the 2 same
>     > composite indexes?
>     >
>     > Thanks
>     > Deepak
>
>     --
>     Sent via pgsql-general mailing list (pgsql-general@postgresql.org
>     <mailto:pgsql-general@postgresql.org>)
>     To make changes to your subscription:
>     http://www.postgresql.org/mailpref/pgsql-general
>
>

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

Предыдущее
От: Gabi Julien
Дата:
Сообщение: Custom cache implemented in a postgresql C function
Следующее
От: Rob Sargent
Дата:
Сообщение: Re: Custom cache implemented in a postgresql C function