| From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Mike Mascari <mascarm(at)mascari(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Weird function behavior from Sept 11 snapshot |
| Date: | 2000-09-12 15:37:00 |
| Message-ID: | 39BE4D9C.1D2F569A@alumni.caltech.edu |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> int8 would still pose some overflow risk (at least for int8 input),
> and would likely be no faster than a float8 implementation, since
> both would require palloc().
Right. On 32-bit machines, int8 is likely to be substantially slower,
since the int8 math is done in a library rather than in a single machine
instruction.
> Your test suggests that the performance differential is *at most*
> 2X --- probably much less in real-world situations where the disk
> pages aren't already cached.
Hmm. sum(int4) on the same table is 1.8 seconds for 7.0.2 (vs 12.5 for
snapshot). But I *am* compiling with asserts turned on for the other
tests (with maybe some other differences too), so maybe it is not (yet)
a fair comparison. Still a pretty big performance difference for
something folks expect to be a fast operation.
- Thomas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Lockhart | 2000-09-12 15:45:08 | Re: Weird function behavior from Sept 11 snapshot |
| Previous Message | Tom Lane | 2000-09-12 15:14:21 | Re: Weird function behavior from Sept 11 snapshot |