Thread: Re: [HACKERS] 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

> 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

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