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:

Previous
From: Bruce Momjian
Date:
Subject: Re: postgresql in FreeBSD jails: proposal
Next
From: Bruce Momjian
Date:
Subject: Re: Minor bug in src/port/rint.c