| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com> |
| Subject: | Re: What exactly is our CRC algorithm? |
| Date: | 2014-11-19 17:03:17 |
| Message-ID: | 28913.1416416597@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Nov 19, 2014 at 11:44 AM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)com> wrote:
>> That's an interesting choice of workload. That sure is heavy on the CRC
>> calculation, but the speed of pg_xlogdump hardly matters in real life.
> But isn't a workload that is heavy on CRC calculation exactly what we
> want here? That way we can see clearly how much benefit we're getting
> on that particular part of the computation. It'll still speed up
> other workloads, too, just not as much.
Heikki's point is that it's an unrealistic choice of CRC chunk size.
Maybe that doesn't matter very much, but it's unproven.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aaron W. Swenson | 2014-11-19 17:03:29 | Move Deprecated configure.in to configure.ac |
| Previous Message | Tom Lane | 2014-11-19 17:01:14 | Re: proposal: plpgsql - Assert statement |