> 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