Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
Re: Avoiding redundant fetches of btree index metapages
- From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
- To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
- Cc: pgsql-hackers(at)postgreSQL(dot)org
- Subject: Re: Avoiding redundant fetches of btree index metapages
- Date: Tue, 25 Apr 2006 13:52:53 -0400
- Message-id: <20060425175253(dot)GC28043(at)surnet(dot)cl>
Tom Lane wrote: > Some experimentation over the weekend turned up the result that $SUBJECT > is a good idea. I had never thought about this much before, figuring > that in a heavily-used index the metapage would stay in cache anyway and > so fetching it at the start of each index search isn't costing any extra > I/O. That's true, but what it does cost is bufmgr contention, and in > fact more than you'd expect because the amount of work actually done > before releasing the page again is minuscule. (See off-list discussion > attached below.) Wow, this is extremely nice. Congratulations on another well-spotted performance problem solved. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
- References:
- Avoiding redundant fetches of btree index metapages
- From: Tom Lane
- Avoiding redundant fetches of btree index metapages
- Prev by Date: Avoiding redundant fetches of btree index metapages
- Next by Date: Re: Catalog Access (was: [GENERAL] Concurrency problem building indexes)
- Previous by thread: Avoiding redundant fetches of btree index metapages
- Next by thread: Re: Avoiding redundant fetches of btree index metapages
- Indexes: