On Tue, Mar 25, 2008 at 01:46:51PM +0100, Zeugswetter Andreas OSB SD wrote:
> > So, I finally decide to focus on the project idea of improving hash
> > index now. It's more valuable , and also challenging.
> >
> > Any suggestion about the project idea of improving hash index?
>
> Imho one thing t
> So, I finally decide to focus on the project idea of improving hash
> index now. It's more valuable , and also challenging.
>
> Any suggestion about the project idea of improving hash index?
Imho one thing to look into is the storage. I do not see any real value
in storing the key itself (espec
Thank you for all of your advices.
I think you're right. I should be more realistic. There are so many
work to do if I want to do some work on Flash disk. It's too difficult
to complete the task only in a summer. Obviously, It's not an
appropriate project idea for GSoC anyway.
Maybe I'll do it in t
>
> On Tue, 25 Mar 2008, mx wrote:
>
> > The atom unit of flash is page(512~2048byte typically). Page are
> > organized into blocks, typically of 32 or 64 pages. All read write and
> > write operations happen at page granularity, but erase operations happen
> > at block granularity.
>
> You made a
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> mx escribió:
>> In my opinion, we have to change Access Method and some part of Storage
>> Managers greatly. Is it too hard for a beginner to serve as a GSoC project?
> It's like 3 orders of magnitude more work than I'd expect a Postgres
> newbie to b
mx escribió:
> In my opinion, we have to change Access Method and some part of Storage
> Managers greatly. Is it too hard for a beginner to serve as a GSoC project?
It's like 3 orders of magnitude more work than I'd expect a Postgres
newbie to be able to finish in a summer.
--
Alvaro Herrera
On Tue, 25 Mar 2008, mx wrote:
The atom unit of flash is page(512~2048byte typically). Page are
organized into blocks, typically of 32 or 64 pages. All read write and
write operations happen at page granularity, but erase operations happen
at block granularity.
You made a subtle switch here
Thank you for your suggestion!
> The biggest problem with the hash index is currently that there's no
> significant performance over b-tree. If you want to work on hash
> indexes, I would suggest doing benchmarking and looking at ways to
> improve performance, before spending time on making it mul
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> mx wrote:
>> By the way, I'm writing proposal for multi-column hash now.
> The biggest problem with the hash index is currently that there's no
> significant performance over b-tree. If you want to work on hash
> indexes, I would suggest doing b
mx wrote:
Hello,Everyone!
I'm a student in China. and I'm preparing for GSocC2008 in these days.
There are two questions about GSoC.
1. There's a paragraph about the Example Proposal Ideas in PostgreSQL Summer
Projects website.
*TODO Items*: A number of the items on our TODO list have been mark
Hello,Everyone!
I'm a student in China. and I'm preparing for GSocC2008 in these days.
There are two questions about GSoC.
1. There's a paragraph about the Example Proposal Ideas in PostgreSQL Summer
Projects website.
*TODO Items*: A number of the items on our TODO list have been marked as
> good
11 matches
Mail list logo