Re: Abbreviated keys for Numeric - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Abbreviated keys for Numeric
Date
Msg-id 87vbis9d3z.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Abbreviated keys for Numeric  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: Abbreviated keys for Numeric  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Re: Abbreviated keys for Numeric  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
>>>>> "Tomas" == Tomas Vondra <tomas.vondra@2ndquadrant.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'sTomas> probably where L1/L2 cache is most important. For large datasetsTomas> the caches are
probablynot as efficient anyway, so the randomTomas> 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)



pgsql-hackers by date:

Previous
From: Kouhei Kaigai
Date:
Subject: Re: OBJECT_ATTRIBUTE is useless (or: ALTER TYPE vs ALTER TABLE for composites)
Next
From: Michael Paquier
Date:
Subject: Re: Bug in pg_dump