From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, Peter Geoghegan <pg(at)heroku(dot)com> |
Subject: | Re: Abbreviated keys for Numeric |
Date: | 2015-02-24 04:09:54 |
Message-ID: | 87vbis9d3z.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>>>> "Tomas" == Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
Tomas> I believe the small regressions (1-10%) for small data sets,
Tomas> might be caused by this 'random padding' effect, because that's
Tomas> probably where L1/L2 cache is most important. For large datasets
Tomas> the caches are probably not as efficient anyway, so the random
Tomas> padding makes no difference,
Except that _your own results_ show that this is not the case.
In your first set of results you claimed a reduction in performance to
91% for a query which is _in no way whatsoever_ affected by any of the
code changes. How is this not noise?
I refer specifically to this case from your spreadsheet:
query select * from (select * from stuff_text order by randtxt offset
100000000000) foo
type text
scale 5
master 26.949
datum 28.051
numeric 29.734
datum 96%
numeric 91%
This query does not invoke any code path touched by either the datum or
numeric patches! The observed slowdown is therefore just noise (assuming
here that your timings are correct).
Whether that case can be improved by tweaking the _text_ abbreviation
code is another question, one which is not relevant to either of the
patches currently in play.
--
Andrew (irc:RhodiumToad)
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-02-24 04:40:39 | Re: Bug in pg_dump |
Previous Message | Kouhei Kaigai | 2015-02-24 04:00:25 | Re: OBJECT_ATTRIBUTE is useless (or: ALTER TYPE vs ALTER TABLE for composites) |