Re: COPY FROM performance improvements
От | Bruce Momjian |
---|---|
Тема | Re: COPY FROM performance improvements |
Дата | |
Msg-id | 200508101654.j7AGskd18845@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: COPY FROM performance improvements ("Luke Lonergan" <llonergan@greenplum.com>) |
Список | pgsql-patches |
Luke Lonergan wrote: > Tom, > > On 8/10/05 8:37 AM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: > > > Luke, I dislike whacking people upside the head, but this discussion > > seems to presume that raw speed on Intel platforms is the only thing > > that matters. We have a few other concerns. Portability, readability, > > maintainability, and correctness all trump platform-specific > > optimizations. The COPY patch as presented lost badly on all those > > counts, and you are lucky that it didn't get rejected completely. > > It's a pleasure working with you too Tom :-) > > Until you present a result on platform that is faster than Alon's in the > code that was modified, our proof still stands that his is 20% faster than > yours. Well, we could write it in assembler and make it even faster. :-) I assume no one is suggesting that, so in such cases, we need to weigh readability with performance. I have not looked at the patch issues, but usually loop unrolling is the opposite of readability, so we have to make a tradeoff. We have used macros in places where function call overhead is a major hit, so we can consider loop unrolling in places that are a major performance hit. The macros we have used have maintained the readability of the function call (unless you look at the macro contents) so perhaps the optimizations you suggest can be done with a similar eye to readability. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-patches по дате отправления: