Re: Abbreviated keys for Numeric

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: Abbreviated keys for Numeric
Дата
Msg-id 87vbis9d3z.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: Abbreviated keys for Numeric  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: Abbreviated keys for Numeric  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Re: Abbreviated keys for Numeric  (Peter Geoghegan <pg@heroku.com>)
Список 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 по дате отправления:

Предыдущее
От: Kouhei Kaigai
Дата:
Сообщение: Re: OBJECT_ATTRIBUTE is useless (or: ALTER TYPE vs ALTER TABLE for composites)
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Bug in pg_dump