Re: [PROPOSAL] Covering + unique indexes.

Поиск
Список
Период
Сортировка
От Thom Brown
Тема Re: [PROPOSAL] Covering + unique indexes.
Дата
Msg-id CAA-aLv5r_EJgTszqYTCmCPjVn0LqRvQG=3L=yWCF2Y-3L4qWwA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PROPOSAL] Covering + unique indexes.  (José Luis Tallón <jltallon@adv-solutions.net>)
Список pgsql-hackers
On 16 September 2015 at 14:03, José Luis Tallón <jltallon@adv-solutions.net> wrote:
On 09/15/2015 06:57 PM, Anastasia Lubennikova wrote:
Proposal Clarification.
I see that discussion become too
complicated. So, I'd like to clarify what we are talking about.

[snip]
What are we doing now:
CREATE UNIQUE INDEX on tbl(f1,f2);
CREATE INDEX on tbl(f1, f2, f3, f4);

[snip]

Suggestions.
CREATE INDEX idx ON tbl (f1, f2, f3) [UNIQUE ON (f1, f2)] [INCLUDE (f4)];

Summarizing some suggestions upthread, it seems like the "best" syntax would be something similar to:

-- Non-unique index + "leaf" information (f4)
CREATE INDEX idx ON tbl (f1, f2, f3) [INCLUDING (f4)]

I guess this would possibly be a path to create indexes... without any actual data in the table.  Sequential scans would be costly, but queries with a predicate matching the sorted columns would be very quick.  Not sure how REINDEX could be made to work with that though.  And might end up requiring something like partitioned indexes.

Disclaimer: I *really* haven't thought this through.
 

-- Unique index on f1,f2, + leaf information (f3)
CREATE UNIQUE INDEX idx ON tbl (f1, f2) [INCLUDING (f3)]

And, even:
ALTER INDEX idx INCLUDING (f4)
 ... which would trigger a REINDEX CONCURRENTLY internally ?

We don't currently have REINDEX CONCURRENTLY.
 
--
Thom

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

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Inaccurate results from numeric ln(), log(), exp() and pow()
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pltcl: sentence improvement