Re: Indexed views?
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Indexed views? |
| Дата | |
| Msg-id | Pine.OSF.4.61.0409121622490.357432@kosh.hut.fi обсуждение исходный текст |
| Ответ на | Re: Indexed views? (Tiago Wright <tiagowright@gmail.com>) |
| Список | pgsql-hackers |
On Sat, 11 Sep 2004, Tiago Wright wrote: > IMHO, it is worth duplicating the mvcc data to all index entries. To > summarize what I understand from this discussion, with the current > method: > > a1 - Index seeks must return invisible tuples because mvcc data is not > found in the index. These tuples are eliminated once the data is read > from the actual data pages. > > a2 - Covered queries are not possible since the data page must be > visited to determine visibility a4 - Indexes must be fully vacuumed before vacuuming the corresponding heap entries > If mvcc data is replicated to the index entries: > > b1 - Index seeks will never return invisible tuples, possibly > eliminating some page reads > > b2 - Covered queries are possible > > b3 - Inserts are not affected performancewise. Deletes must now visit > every index entry, which is a larger cost. Updates must visit every > index entry too. It may be possible to reduce the cost of update if > the indexed data is not affected, since the new index entry will > likely end up in the same page as the index entry that must be > deleted, so no extra page reads would be necessary in this scenario. b4 - Heap and index pages can be vacuumed independently. > Since the great majority of performance issues are related to select > queries, the benefit of eliminating invisible tuple page fetches and > supporting covered queries probably outweight the extra cost of > updating index entries. And once covered queries are supported, it > would be possible to build indexed views or multi-table indexes that > can address some of the most performance demanding queries out there. > > I am wondering whether it would be possible to measure the costs of a1 > and a2 above and compare with the probable costs for b3. It seems to > me that applications for which b3 are most expensive are also those > for which a1 would be most expensive, and since selects are much more > common than updates, could one offset the other in the long run? Can > anyone shed some light on these? If it seems that there are some cases where it's better to have the visibility information in the index and some cases where not, I think we could support both kinds of indexes and let the DBA choose. - Heikki
В списке pgsql-hackers по дате отправления: