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