Re: Advice: Where could I be of help? - Mailing list pgsql-hackers
From | Mike Benoit |
---|---|
Subject | Re: Advice: Where could I be of help? |
Date | |
Msg-id | 1033593869.14795.13.camel@mikeb.staff.netnation.com Whole thread Raw |
In response to | Advice: Where could I be of help? ("Curtis Faith" <curtis@galtair.com>) |
List | pgsql-hackers |
I'm not a developer, but I know this item on the todo list has been a magor pain in my side for quite a while: # Make IN/NOT IN have similar performance to EXISTS/NOT EXISTS [http://momjian.postgresql.org/cgi-bin/pgtodo?exists] Any time I've attempted to use this feature, the query cost is in the millions according to "explain", which of course makes it useless to even execute. :( I have managed to work around this performance problem, but it sure would be nice if PGSQL handled such cases better. There are probably thousands of other todo items you could spend your time on that would be more useful to more people, but this is just one suggestion. :) On Wed, 2002-10-02 at 13:13, Curtis Faith wrote: > All, > > I'd like to help work on some 7.4 features, however, since you've not seen > my name before, I'm obviously new to the list and the org. > > I really like working on speed optimizations and rewrites. I have 15 years > experience with C++-based systems and databases, and have worked on > commercial database engines (i.e. indexing and query execution systems), sql > execution and optimization, various lex and yacc based compilers and > parsers. I've generally been able to get code to perform as well or better > than competitive systems with similar functionality, and usually have been > able to beat other code by 3 to 10 X. My unix experience is reasonable but > I'm not an expert. > > Any suggestions for where to start? I don't mind digging into very hairy > code or large problems. I'm willing to run the risk of a patch not being > accepted (for large changes) since I'll make sure whatever I do is well > known to those who will do the accept/deny and the approach approved of > ahead of time. > > Since I'm new here, I'm thinking a problem that would not otherwise get > handled by the experienced group would be the best place to start. Where is > the system especially slow? > > I've read the TODO's, and the last five months of the archives for this > list, so I have some general ideas. > > I've also had a lot experience marketing to I.T. organizations so I'd be > happy to help out on the Product Marketing for PostgreSQL advocacy, i.e. > developing a marketing strategy, press releases, etc. > > - Curtis > > Curtis Faith > Principal > Galt Capital, LLP > > ------------------------------------------------------------------ > Galt Capital http://www.galtcapital.com > 12 Wimmelskafts Gade > Post Office Box 7549 voice: 340.776.0144 > Charlotte Amalie, St. Thomas fax: 340.776.0244 > United States Virgin Islands 00801 cell: 340.643.5368 > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org >
pgsql-hackers by date: