Re: Index only scan paving the way for "auto" clustered tables?
От | Robert Haas |
---|---|
Тема | Re: Index only scan paving the way for "auto" clustered tables? |
Дата | |
Msg-id | CA+TgmobuJpLirKvQwhOOp6bmSbRSga+Ctj=Z7wb9zAfFaz7rFg@mail.gmail.com обсуждение исходный текст |
Ответ на | Index only scan paving the way for "auto" clustered tables? (Royce Ausburn <royce.ml@inomial.com>) |
Ответы |
Re: Index only scan paving the way for "auto"
clustered tables?
|
Список | pgsql-hackers |
On Tue, Oct 11, 2011 at 7:08 AM, Royce Ausburn <royce.ml@inomial.com> wrote: > I wonder, could the recent work on index only scans pave the way for auto clustered tables? Consider a wide, mostly inserttable with some subset of columns that I'd like to cluster on. I'm after locality of tuples that are very frequentlyfetched together, but not keen on the downtime for a cluster, nor the maintenance that it requires. Would it bea stretch to have an index that branches on the subset of "cluster" columns, but still stores all the columns, making ita covering index? Given that we can already index concurrently, such an index would not require downtime, and would beself maintaining. From my understanding of the index-only scan implementation, I suspect that such an index would effectivelygive locality, with some caveats… I guess we could do that, but I'm not convinced there would be much benefit. The only thing you'd be saving would be the cost of keeping the tuples sorted by only the high-order columns rather than all of them, and I doubt that's significant. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: