Re: [GSoC] (Is it OK to choose items without % mark in theToDoList) && (is it an acceptable idea to build index on Flash Disk) - Mailing list pgsql-hackers
From | mx |
---|---|
Subject | Re: [GSoC] (Is it OK to choose items without % mark in theToDoList) && (is it an acceptable idea to build index on Flash Disk) |
Date | |
Msg-id | ded849dd0803241910s1e701c70nc30d6cf4b4da4c29@mail.gmail.com Whole thread Raw |
In response to | Re: [GSoC] (Is it OK to choose items without % mark in theToDoList) && (is it an acceptable idea to build index on Flash Disk) ("Heikki Linnakangas" <heikki@enterprisedb.com>) |
Responses |
Re: [GSoC] (Is it OK to choose items without % mark in
theToDoList) && (is it an acceptable idea to build index on Flash Disk)
Re: [GSoC] (Is it OK to choose items without % mark in theToDoList) && (is it an acceptable idea to build index on Flash Disk) |
List | pgsql-hackers |
Thank you for your suggestion!<br /><br />> The biggest problem with the hash index is currently that there's no<br />>significant performance over b-tree. If you want to work on hash<br />> indexes, I would suggest doing benchmarkingand looking at ways to<br /> > improve performance, before spending time on making it multi-column<br />>capable. And missing WAL logging is a big issue as well.<br /><br />It's a good suggestion! My work is useless if theperformance of hash index is not effective enough.<br /> I'll adopt your suggestion to consider improving hash performanceat first. It's a more challenging and exciting work.<br /><br />On Tue, Mar 25, 2008 at 12:23 AM, Heikki Linnakangas<<a href="mailto:heikki@enterprisedb.com">heikki@enterprisedb.com</a>> wrote:<br /><br />> Maybe, hardto tell without more details. What difference does it make<br />> if the b-tree is on a flash device, as opposed todisk? What's different<br />> in general when you run on a flash disk?<br />> <br /> > The "embedded server" ideain the "not wanted" list refers to the idea<br />> of running PostgreSQL in the same process as the client. If I understood<br/>> you correctly, you're proposing something quite different.<br /> > <br /><br />OK, I'll explain itin more details. <br /><br />The atom unit of flash is page(512~2048byte typically).<br />Page are organized into blocks,typically of 32 or 64 pages.<br />All read write and write operations happen at page granularity, but erase operationshappen at block granularity.<br /><br />Flash has a weird characteristic "erase-before-write".You can't just overwritea page, You have to erase the whole blocks and then write the page. So read operation is faster than write operation(about 2~200times by different device).<br /><br />It's a big problem when we just run database designed for magneticdisk.We just overwrite a page when we update B-Tree, but it's not a good way to update for flash disk. Currently,there are some research results on this problem. They use a method similar to the Log-structured File Systems and every node is encoded by many log entries. So, they can reduce update using log.<br /><br />In my opinion, we have to change Access Method and some part of Storage Managers greatly. Is it too hard for a beginner to serveas a GSoC project?<br /><br /><br />Finally, please make some suggestions, thanks!<br /><br />-- <br /> Have a goodday;-)<br />Best Regards,<br />Meng Xiao<br /><br />━━━━━━━━━━━━━━━━━━━━━━━━━<br />Data and Knowledge Engineering ResearchCenter,CS&T<br />Harbin Institute of Technology, Harbin, China<br />Gtalk: <a href="mailto:mx.cogito@gmail.com">mx.cogito@gmail.com</a><br/> MSN: <a href="mailto:cnEnder@live.com">cnEnder@live.com</a><br/> Blog: <a href="http://xiaomeng.yo2.cn">http://xiaomeng.yo2.cn</a>
pgsql-hackers by date: