Re: [HACKERS] Dllist public/private part
Bruce Momjian [EMAIL PROTECTED] wrote: Mendola Gaetano wrote: I certainly would like to see Dllist removed too. 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 ? What TODO item where you looking at? I see the http://developer.postgresql.org/todo.php and for someone that want start to code is really hard reading for example: . Cache last known per-tuple offsets to speed long tuple access what can do a postgres source beginner after reading that sentence ? May be is more usefull if a very postgres source expert, like Bruce Momjian or Tom Lane, will compile a more detailed list about what to do like: We need a really efficient double linked list with this interface blah blah blah or something like that I hope I was clear enough Regards Gaetano Mendola ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Dllist public/private part
Mendola Gaetano wrote: Bruce Momjian [EMAIL PROTECTED] wrote: Mendola Gaetano wrote: I certainly would like to see Dllist removed too. 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 ? What TODO item where you looking at? I see the http://developer.postgresql.org/todo.php and for someone that want start to code is really hard reading for example: . Cache last known per-tuple offsets to speed long tuple access what can do a postgres source beginner after reading that sentence ? May be is more usefull if a very postgres source expert, like Bruce Momjian or Tom Lane, will compile a more detailed list about what to do like: We need a really efficient double linked list with this interface blah blah blah or something like that I hope I was clear enough I understand. If you read the developers FAQ, it mentions that you should probably ask on the hackers list about the details of specific items. The item you mentioned had a whole email thread recently, so there is a long explaination and we can guide you through it so you understand the issues. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Dllist public/private part
Tom Lane [EMAIL PROTECTED] wrote: Mendola Gaetano [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Dllist public/private part
Mendola Gaetano wrote: Tom Lane [EMAIL PROTECTED] wrote: Mendola Gaetano [EMAIL PROTECTED] 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). I certainly would like to see Dllist removed too. 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 ? What TODO item where you looking at? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Dllist public/private part
I'm improving the Dllist in these direction:
1) Avoid if statements in insertion/remove phase, for instance now the
AddHeader appear like this:
void
DLAddHead(Dllist *l, Dlelem *e)
{
Dlelem *where = l-dll_master_node-dle_next;
e-dle_next = where;
e-dle_prev = where-dle_prev;
where-dle_prev-dle_next = e;
where-dle_prev = e;
e-dle_list = l;
}
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...
In the file dllist.h is not clear what is the public part and the private
part
of the implementation in particulary I see that somewhere in the code
there is the assumption that an Empty dllist is zeroed instead of
use DLInitList, for example this is the way to initialize a struct that
contain a Dllist itself:
cp = (CatCache *) palloc0(sizeof(CatCache) + NCCBUCKETS * sizeof(Dllist));
this break my optimization because in my implementation a
dllist is
typedef struct Dllist
{
Dlelem *dll_master_node;
} Dllist;
and not anymore:
typedef struct Dllist
{
Dlelem *dll_head;
Dlelem *dll_tail;
} Dllist;
and is empty if list-dll_master_node-dle_next and
list-master_node-dle_prev are pointing to
list-master_node ( previously allocated in DLInitList).
What should I do ? Forget the point 1) ?
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Dllist public/private part
Mendola Gaetano [EMAIL PROTECTED] 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). regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
