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
Re: Abbreviated keys for Numeric |
Список | 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 по дате отправления: