Robert Treat wrote: > On Tue, 2003-11-18 at 17:31, Sailesh Krishnamurthy wrote: >> >>One step at a time :-) >> >>Actually a big problem is figuring out new pieces for the >>projects. Most of the items in the TODO list are way too much for a >>class project - we gave 'em 3 weeks to make the Hash GroupedAgg work >>for large numbers of unique values (by using a form of hybrid hashing).
>>Another thing I toyed with was having an implementation of a >>Tid-List-Fetch .. sorting a TID-list from an index and fetching the >>records of the relation off the sorted list for better IO >>performance. AFAICT something like this isn't present yet .. can pgsql >>do this already ? > While some form of bitmapped indexing would be cool, other ideas might > be to implement different buffer manager strategies. I was impressed by > how quickly Jan was able to implement ARC over LRU, but there are a host > of other strategies that could also be implemented. Remember that interview with Jim Gray: http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=43 "Certainly we have to convert from random disk access to sequential access patterns. Disks will give you 200 accesses per second, so if you read a few kilobytes in each access, you're in the megabyte-per-second realm, and it will take a year to read a 20-terabyte disk. If you go to sequential access of larger chunks of the disk, you will get 500 times more bandwidth—you can read or write the disk in a day. So programmers have to start thinking of the disk as a sequential device rather than a random access device." Isn't a TID-List-Fetch implementation a crucial first step in the right direction? Mike Mascari [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org