Re: Dllist public/private part - Mailing list pgsql-hackers

From Mendola Gaetano
Subject Re: Dllist public/private part
Date
Msg-id 00b401c33fc9$9bacb7f0$10d4a8c0@mm.eutelsat.org
Whole thread Raw
In response to Dllist public/private part  ("Mendola Gaetano" <mendola@bigfoot.com>)
Responses Re: Dllist public/private part  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> "Mendola Gaetano" <mendola@bigfoot.com> writes:
> > I'm improving the Dllist in these direction:
>
> AFAIR, catcache.c is the *only* remaining backend customer for Dllist,
> and so any improvement for Dllist that breaks catcache is hardly an
> improvement, no?
>
> > 1) Avoid "if" statements in insertion/remove phase, for instance now the
> > AddHeader appear like this:
>
> <shrug> ... unless you can convert DLAddHead into a inline macro,
> I doubt there'll be any visible performance difference.
> > 2) Not using a malloc but using a "special" malloc that not perform
> >    a malloc for each request but do a BIG malloc at first request...
>
> It would make more sense to migrate Dllist to use palloc.  That's not
> compatible with its use in frontend libpq; I've been speculating about
> splitting off libpq to have a separate implementation instead of trying
> to share code.  I believe libpq only uses Dllist for the
> pending-notify-events list, for which the code is poorly optimized
> anyway (we don't need a doubly-linked list for that).

This mean that is waste of time work on dllist.
I seen that exist a TODO list about "features",
exist a list about: "code to optimize" ?


Regards
Gaetano Mendola




pgsql-hackers by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: vacuum bug
Next
From: Andreas Pflug
Date:
Subject: Index expressions: how to recreate