From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ALTER TABLE ADD COLUMN fast default |
Date: | 2018-02-20 21:25:14 |
Message-ID: | 38879bd0-2771-ed93-494b-72b4e1c7a28f@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 02/20/2018 09:36 PM, Andres Freund wrote:
> Hi,
>
> On 2018-02-20 21:28:40 +0100, Tomas Vondra wrote:
>> I don't quite understand why would this case need the TPC-H tests, or
>> why would TPC-H give us more than the very focused tests we've already
>> done.
>
> Because a more complex query shows the cost of changing cache access
> costs better than a trivial query. Simplistic queries will often
> e.g. not show cost of additional branch predictor usage, because the
> branch history is large enough to fit the simple query. But once you go
> to a more complex query, and that's not necessarily the case anymore.
>
>
>> The first test was testing a fairly short query where any such
>> additional overhead would be much more obvious, compared to the TPC-H
>> queries that usually do a lot of other expensive stuff.
>
> Unfortunately such reasoning IME doesn't work well with cpu-bound stuff.
>
OK, point taken. I'll do the tests and report the results.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2018-02-20 22:05:37 | Re: SHA-2 functions |
Previous Message | Tomas Vondra | 2018-02-20 21:23:54 | Hash Joins vs. Bloom Filters / take 2 |