Tom Lane escreveu: > Hmm ... I'd not looked at that patch before, but now that I have I think > it's gone pretty seriously off on the overdesigned-and-inefficient end > of the spectrum. Turning RelationGetFillFactor and friends from simple > macros into functions that are probably *at least* a thousand times slower > than the macros doesn't seem like a good idea at all. Deconstructing a > reloptions datum is supposed to be done once by the relcache, not every > time one of the values is needed. Frankly I'd throw the entire thing > away and go back to a hardwired set of options feeding into a predefined > struct that's held by the relcache and examined by callers. > I think about that but I don't do any benchmarks after I finished the patch. We can do an exception as the current code do for "oids" and don't rip out the StdRdOptions just to maitain the RelationGetFillFactor() and others like a macro. Honestly, I don't like to bring RelationGet*() to reloptions.c but we can always refactor that before committing it.
Alvaro, let me know if you want me to send another patch; or will you do it? I have some small corrections too. -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
