> Two things I regret: one is being unable to see the changes as patches > the way you applied them, to get a sense of how the code evolved. > Unfortunately the interface to CVS via web does not allow me to see it, > or I don't know how to use it. It's not that important, however, > because I was already somewhat familiar with the code.
You can do cvs diff commands between versions... > The other is that now I am left without a graduate project :-( I will > continue looking at the TODO list for something that's of an appropiate > size for me. (Professors here don't have any but the slightest idea of > Postgres, so they aren't of any help.) I'm still thinking on > implementing a replacement for the regex engine based on the Shift-or > algorithm, if only to have a speed comparison with traditional engines. How about working on hash indexes? They have several problems at the moment that make them unusable: 1. They are really slow to build 2. They have poor concurrency 3. They are not any faster than btree indexes for '=' operators (which is lame!) 4. They are not WAL logged or recoverable 5. They cannot be marked UNIQUE (IIRC) Since you already have experience in the postgres indexing arena, you could transfer your skills to this new index method easily? Apparently berkelydb has good hash index code that could be looked at... Other things to look at perhaps would be that GiST indexes have poor concurrency and aren't WAL logged. Also, how about looking into the fact that you cannot store constants in functional indexes? Or what about bitmap indexes? Cheers, Chris ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
