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


Wed, 2 Oct 2002 16:13:25 -0400
"Curtis Faith" <curtis@galtair.com>
Advice: Where could I be of help?
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
> 


02 Oct 2002 14:24:29 -0700
Mike Benoit <mikeb@netnation.com>
Re: Advice: Where could I be of help?

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

Wed, 2 Oct 2002 17:27:55 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Advice: Where could I be of help?
"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


02 Oct 2002 18:33:19 -0400
Neil Conway <neilc@samurai.com>
Re: Advice: Where could I be of help?
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

Wed, 02 Oct 2002 18:54:33 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Advice: Where could I be of help? 
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

Wed, 2 Oct 2002 22:29:13 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Advice: Where could I be of help?
>
> 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



Sat, 5 Oct 2002 08:31:05 +0200
Mario Weilguni <mweilguni@sime.com>
Re: [HACKERS] Advice: Where could I be of help?
> 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


05 Oct 2002 15:53:47 +0900
Thomas O'Dowd <tom@nooper.com>
Re: [HACKERS] Advice: Where could I be of help?
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

Mon, 7 Oct 2002 09:24:17 +0200
Karel Zak <zakkr@zf.jcu.cz>
Re: [HACKERS] Advice: Where could I be of help?