| Lists: | pgsql-hackers-win32pgsql-patches |
|---|
| From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | <pgsql-hackers-win32(at)postgresql(dot)org>, "PostgreSQL-patches" <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: explain analyze timings |
| Date: | 2005-03-20 18:37:13 |
| Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCE6C70EB@algol.sollentuna.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers-win32 pgsql-patches |
>> Here's a patch that does just this.
>
>This seems about the ugliest and most intrusive way you could have
>done it :-(. A judicious typedef and macro or two could eliminate
>most of the #ifdefs and code duplication, thereby preserving
>readability...
Well, I certainly can't argue with that, now that you mention it ;-)
Here is a second attempt, hope it's closer to what you expected.
I still left two #ifdefs in there, for the addition and subtraction of
timeval:s specifically. They could be made functions/macros too, just
not sure if it's worth it.
Tested on win32 and linux (now that it changes non-win32 specific code
as well).
//Magnus
| Attachment | Content-Type | Size |
|---|---|---|
| win32_instr2.patch | application/octet-stream | 8.8 KB |
| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
| Cc: | pgsql-hackers-win32(at)postgresql(dot)org, "PostgreSQL-patches" <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: explain analyze timings |
| Date: | 2005-03-20 22:30:20 |
| Message-ID: | 13968.1111357820@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers-win32 pgsql-patches |
"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> Here is a second attempt, hope it's closer to what you expected.
Better --- patch applied with some minor editorialization.
> I still left two #ifdefs in there, for the addition and subtraction of
> timeval:s specifically. They could be made functions/macros too, just
> not sure if it's worth it.
Probably not. What bothers me more is the unconditional use of a
static inline function; but IIRC we are only supporting gcc-based builds
on Windows, so that probably isn't worth fixing either.
regards, tom lane