> 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 Since you already have experience in the postgres indexing arena, you could transfer your skills to this new index method easily? Other things to look at perhaps would be that GiST indexes have poor concurrency and aren't WAL logged. Also, how about looking at the fact that you cannot store constants in functional indexes? Cheers, Chris ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
