Ühel kenal päeval, T, 2006-07-11 kell 10:46, kirjutas Josh Berkus: > Tom, > > > Obviously a tree containing many such pages would be awfully inefficient > > to search, but I think a more common case is that there are a few wide > > entries in an index of mostly short entries, and so pushing the hard > > limit up a little would add some flexibility with little performance > > cost in real-world cases. > > > > Have I missed something? Is this worth changing? > > Not sure. I don't know that the difference between 2.7K and 3.9K would > have ever made a difference to me in any real-world case.
One (hopefully) soon-to-be real-world case is index-only queries. We discussed one approach with Luke and he expressed interest in getting actually done in not too distant future. > If we're going to tinker with this code, it would be far more valuable > to automatically truncate b-tree entries at, say, 1K so that they could > be efficiently indexed. That would not work, if we want to get all data from indexes. Maybe compressing the keys (like we do for TOAST) would be a better solution. > Of course, a quick archives search of -SQL, -Newbie and -General would > indicate how popular of an issue this is. It may become populat again, when we will be able to do index-only scans. -- ---------------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
