Re: portability of "designated initializers"

Поиск
Список
Период
Сортировка
От Euler Taveira de Oliveira
Тема Re: portability of "designated initializers"
Дата
Msg-id 4928B454.6030301@timbira.com
обсуждение исходный текст
Ответ на Re: portability of "designated initializers"  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: portability of "designated initializers"  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
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/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Euler Taveira de Oliveira
Дата:
Сообщение: Re: portability of "designated initializers"
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Cool hack with recursive queries