Re: discarding duplicate indexes

Поиск
Список
Период
Сортировка
От Gavin Flower
Тема Re: discarding duplicate indexes
Дата
Msg-id 50D2CBC4.6070006@archidevsys.co.nz
обсуждение исходный текст
Ответ на discarding duplicate indexes  (Josh Kupershmidt <schmiddy@gmail.com>)
Ответы Re: discarding duplicate indexes
Re: discarding duplicate indexes
Список pgsql-hackers
<div class="moz-cite-prefix">On 20/12/12 14:57, Josh Kupershmidt wrote:<br /></div><blockquote
cite="mid:CAK3UJRGf6pq-adXT6fFMGQOriwH04JOqE_69j3wZUaf0uC2HXg@mail.gmail.com"type="cite"><pre wrap="">CREATE TABLE test
(idint);
 
CREATE INDEX test_idx1 ON test (id);
CREATE INDEX test_idx2 ON test (id);</pre></blockquote> I initially misread your example code, but after I realised my
mistake,I thought of an alternative scenario that might be worth considering.<br /><pre wrap="">CREATE TABLE test (id
int,int sub, text payload);
 
CREATE INDEX test_idx1 ON test (id, sub);
CREATE INDEX test_idx2 ON test (id);


<big><font face="Liberation Serif, serif"><font size="3"><big>Now <font face="Liberation Mono,
monospace">test_idx2</font>is logically included in <font face="Liberation Mono, monospace">test_idx1</font>, but if
themajority of transactions only query on <font face="Liberation Mono, monospace">id</font>, then <font
face="LiberationMono, monospace">test_idx2</font> would be more better as it ties up less
RAM</big></font></font></big>

</pre><p class="western" style="margin-bottom: 0cm">Cheers,<br /> Gavin<pre wrap=""></pre>

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

Предыдущее
От: Brendan Jurd
Дата:
Сообщение: Re: operator dependency of commutator and negator, redux
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1