Re: Abbreviated keys for Numeric

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)

In response to

Responses

Browse pgsql-hackers by date

  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)