| From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Stephen Frost" <sfrost(at)snowman(dot)net> |
| Cc: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, "Greg Stark" <gsstark(at)mit(dot)edu>, "Dann Corbit" <DCorbit(at)connx(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Merge algorithms for large numbers of "tapes" |
| Date: | 2006-03-10 00:07:05 |
| Message-ID: | C0360329.1EE2E%llonergan@greenplum.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom,
On 3/9/06 3:59 PM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Possibly nothing. However, from an algorithmic point of view the
> CVS-tip code *is* two-pass-sort, given adequate work_mem and no
> requirement for random access. Further, the available profile data
> doesn't show any indication that the logtape.c code is eating 3/4ths
> of the time (at least not after we fixed the ltsReleaseBlock problem).
> So I basically do not believe Luke's assertion that removing logtape.c
> is going to produce a 4X speedup. Maybe it's time to produce some code
> that we can all test.
Let's be fair - I've never asserted that logtape.c is solely responsible for
the performance.
- Luke
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Luke Lonergan | 2006-03-10 00:08:23 | Re: Merge algorithms for large numbers of "tapes" |
| Previous Message | Luke Lonergan | 2006-03-10 00:04:48 | Re: Merge algorithms for large numbers of "tapes" |