From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | Jeff <threshar(at)torgo(dot)978(dot)org>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: list rewrite committed |
Date: | 2004-05-28 06:09:14 |
Message-ID: | 15359.1085724554@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway <neilc(at)samurai(dot)com> writes:
>> If not, would something like a pg_bench exercise the new code enough to
>> see the results?
> Something like TPC-H would be better, I'd think.
You'd only be likely to notice a difference in queries with hundreds of
selected columns, CASE expressions with hundreds of alternatives, that
kind of thing. I doubt that any of the standard benchmarks really
stress this sort of problem.
As Neil mentioned, we'd already tamped down the more common cases with
the FastList kluge. But there definitely are cases that we'd not
covered with FastList, some because it was notationally impractical
and some because we'd just not noticed a problem. For instance, here
http://archives.postgresql.org/pgsql-hackers/2004-03/msg00696.php
are some profiles documenting a case where nearly 40% of the runtime
goes into lappend's in 7.4. I haven't had time to repeat the test case
but I'd think that time is near-zero in CVS tip.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2004-05-28 06:19:43 | Re: Win32, PITR, nested transactions, tablespaces |
Previous Message | Tom Lane | 2004-05-28 05:32:30 | Re: Win32, PITR, nested transactions, tablespaces |