On 24.2.2015 05:09, Andrew Gierth wrote: >>>>>> "Tomas" == Tomas Vondra <tomas.von...@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'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).
I don't see how that contradicts what I said? Weren't you claiming that changes / random padding in unrelated functions may impact other places by introducing different patterns of cache misses etc? But yes, I do agree the first set of results is rather noisy, at least partially due to running on CPU (i7-4770R) with some power-management features etc. That's why I did the follow-up tests on a different system with CPUs that don't not do that - at least the i5 does not, and the results are much better IMHO. > 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. I don't think I suggested that. -- Tomas Vondra http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers