Re: [HACKERS] Self-modifying code
Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > I just read an article on LWN.net about the usage of self-modifying code > > for selecting the optimum code for a given operation at run time. > > That went out with hula hoops, I think. For sure the security > implications of making your code segment writable mean that the bar for > "is it worth it" is a WHOLE lot higher than "it might possibly make TAS > a bit faster". Actually I was thinking in the issue with defining different sets of TAS for SMP versus non-SMP. There was discussion that suggested handing off two set of binaries, one for each configuration. So it's not just "it might possibly" but rather a possible answer to that problem, which was not mentioned as minor and for which a solution was not found AFAIR. However it's not something that I'll personally code, so I'll let somebody else argue about it if they really care about the issue. I just felt the need to mention it. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Self-modifying code
Alvaro Herrera <[EMAIL PROTECTED]> writes: > I just read an article on LWN.net about the usage of self-modifying code > for selecting the optimum code for a given operation at run time. That went out with hula hoops, I think. For sure the security implications of making your code segment writable mean that the bar for "is it worth it" is a WHOLE lot higher than "it might possibly make TAS a bit faster". regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Self-modifying code
I just read an article on LWN.net about the usage of self-modifying code for selecting the optimum code for a given operation at run time. This is probably not a highly portable technique, but Linux has definitions for i386 and the amd64 archs, so that would cover the most common scenarios. This could be useful to provide different TAS implementations depending on the actual system the code is running on. The article is here: http://lwn.net/SubscriberLink/164121/d88fddbb5606a938/ The i386 code is here: http://lxr.linux.no/source/include/asm-i386/system.h#L288 -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
