From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com> |
Subject: | Re: [HACKERS] External Sort timing debug statements |
Date: | 2005-10-04 03:51:18 |
Message-ID: | 3551.1128397878@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> I'm not actually involved in this so maybe I'm completely off base here. But
> wouldn't you want to know how many tuples are being sorted and how many data
> are being written in these runs in order to be able to actually make sense of
> these timing measurements?
In all plausible test cases you should be able to know the total number
of tuples being sorted independently. Counting the tuples processed in
each run would require extra per-tuple overhead, which I'd rather avoid
until proven necessary.
The total-data-volume aspect may or may not be interesting, not sure
yet. Let's see what we can learn from the present low-impact patch.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2005-10-04 03:51:44 | Re: effective SELECT from child tables |
Previous Message | Tom Lane | 2005-10-04 03:31:39 | Re: New Point Releases Available |
From | Date | Subject | |
---|---|---|---|
Next Message | Sokolov Yura | 2005-10-04 08:24:30 | Patch for PLPYTHONU - adding TD["relname"] |
Previous Message | Greg Stark | 2005-10-04 03:31:21 | Re: [HACKERS] External Sort timing debug statements |