Thread
-
Advice: Where could I be of help?
Curtis Faith <curtis@galtair.com> — 2002-10-02T20:13:25Z
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
-
Re: Advice: Where could I be of help?
Mike Benoit <mikeb@netnation.com> — 2002-10-02T21:24:29Z
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 >
-
Re: Advice: Where could I be of help?
Bruce Momjian <pgman@candle.pha.pa.us> — 2002-10-02T21:27:55Z
I would read the developers corner stuff, the developers FAQ, pick a TODO item, and try a patch. It's that simple. Feel free to contact me for specific advice. I am on chat at: AIM bmomjian ICQ 151255111 Yahoo bmomjian MSN root@candle.pha.pa.us IRC #postgresql vis efnet --------------------------------------------------------------------------- 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 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: Advice: Where could I be of help?
Neil Conway <neilc@samurai.com> — 2002-10-02T22:33:19Z
"Curtis Faith" <curtis@galtair.com> writes: > 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. [...] > Any suggestions for where to start? Well, I'd suggest working on what you find interesting -- there is room for improvement in just about every area of the system, so don't let us dictate how you spend your free time. That said, the code for hash indexes requires some *major* changes, and AFAIK none of the core developers are planning on working on it any time soon (and since the hash index could is somewhat isolated, it might be a good place to start). There's also plenty of work remaining to be done for replication -- the pgreplication project could use some help. You could also improve PL/pgSQL -- there are a bunch of relatively minor improvements that could be made. You could also try implementing bitmap indexes, or improving GEQO (the genetic-algorithm based query optimizer). HTH, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
-
Re: Advice: Where could I be of help?
Tom Lane <tgl@sss.pgh.pa.us> — 2002-10-02T22:54:33Z
Bruce Momjian <pgman@candle.pha.pa.us> writes: > I would read the developers corner stuff, the developers FAQ, pick a > TODO item, and try a patch. It's that simple. Yup. I'd also suggest starting with something relatively small and localized (the nearby suggestion to fix IN/EXISTS, for example, is probably not a good first project --- and anyway I was going to work on that myself this month ;-)). Neil Conway's thought of working on plpgsql seems a good one to me; and as he says, there's lots of other possibilities. What do you find interesting in the TODO list? regards, tom lane
-
Re: Advice: Where could I be of help?
Bruce Momjian <pgman@candle.pha.pa.us> — 2002-10-03T02:29:13Z
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I would read the developers corner stuff, the developers FAQ, pick a > > TODO item, and try a patch. It's that simple. > > Yup. I'd also suggest starting with something relatively small and > localized (the nearby suggestion to fix IN/EXISTS, for example, is > probably not a good first project --- and anyway I was going to work > on that myself this month ;-)). That's good news. I am getting a little embarassed because I had to explain the work arounds to someone this week, twice. As it stands now, when is EXISTS quicker than IN. It isn't always, right? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
-
Re: [HACKERS] Advice: Where could I be of help?
Mario Weilguni <mweilguni@sime.com> — 2002-10-05T06:31:05Z
> > 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. Hi, just an idea, but if you're still searching something to work on, you might want to take a look on the deadlock problem with foreign keys. It seems there's a new kind of lock needed here, because it's possible to deadlock backends where no real deadlock situation occurs. IMO this is one of the biggest problems in postgres now, because for foreign keys are widely used and - even if not deadlocking - performance is limited because of the many "select ... for update" the fk system uses limit concurrency to one at a time in many situations. Regards, Mario Weilguni
-
Re: [HACKERS] Advice: Where could I be of help?
Thomas O'Dowd <tom@nooper.com> — 2002-10-05T06:53:47Z
> just an idea, but if you're still searching something to work on, you might want to take > a look on the deadlock problem with foreign keys. It seems there's a new kind of lock needed here, > because it's possible to deadlock backends where no real deadlock situation occurs. > > IMO this is one of the biggest problems in postgres now, because for foreign keys are widely used and > - even if not deadlocking - performance is limited because of the many "select ... for update" the fk system > uses limit concurrency to one at a time in many situations. That gets my vote too for what its worth... I had to remove most of the FK references from my tables and just replaced them with triggers as the amount of deadlocks I was getting in stress tests was killing me. Tom. -- Thomas O'Dowd. - Nooping - http://nooper.com tom@nooper.com - Testing - http://nooper.co.jp/labs
-
Re: [HACKERS] Advice: Where could I be of help?
Karel Zak <zakkr@zf.jcu.cz> — 2002-10-07T07:24:17Z
On Sat, Oct 05, 2002 at 03:53:47PM +0900, Thomas O'Dowd wrote: > > just an idea, but if you're still searching something to work on, you might want to take > > a look on the deadlock problem with foreign keys. It seems there's a new kind of lock needed here, > > because it's possible to deadlock backends where no real deadlock situation occurs. > > > > IMO this is one of the biggest problems in postgres now, because for foreign keys are widely used and > > - even if not deadlocking - performance is limited because of the many "select ... for update" the fk system > > uses limit concurrency to one at a time in many situations. > > That gets my vote too for what its worth... I had to remove most of the > FK references from my tables and just replaced them with triggers as the > amount of deadlocks I was getting in stress tests was killing me. <jog-to-developers> ... maybe try use latest MySQL with InnoDB tables :-) </jog-to-developers> Karel -- Karel Zak <zakkr@zf.jcu.cz> http://home.zf.jcu.cz/~zakkr/ C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz