Re: Sort support for macaddr8

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Melanie Plageman <melanieplageman(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Sort support for macaddr8
Date: 2019-06-04 21:30:03
Message-ID: 20190604213003.wwul254zt3owlqx4@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 04, 2019 at 01:49:23PM -0400, Stephen Frost wrote:
>Greetings,
>
>* Melanie Plageman (melanieplageman(at)gmail(dot)com) wrote:
>> Peter and I implemented this small (attached) patch to extend
>> abbreviated key compare sort to macaddr8 datatype (currently supported
>> for macaddr).
>
>Nice.
>
>> I think that that seems like an improvement. I was thinking of
>> registering this patch for the next commitfest. Is that okay?
>
>Sure.
>
>> I was just wondering what the accepted way to test and share
>> performance numbers is for a small patch like this. Is sharing DDL
>> enough? Do I need to use pg_bench?
>
>Detailed (enough... doesn't need to include timing of every indivudal
>query, but something like the average timing across 5 runs or similar
>would be good) results posted to this list, with enough information
>about how to reproduce the tests, would be the way to go.
>
>The idea is to let others also test and make sure that they come up with
>similar results to yours, and if they don't, ideally have enough
>information to narrow down what's happening / what's different.
>

Yeah, there's no "approved way" to do performance tests the contributors
would have to follow. That applies both to tooling and how detailed the
data need/should be. Ultimately, the goal is to convince others (and
yourself) that the change is an improvement. Does a simple pgbench
script achieve that? Cool, use that. Do you need something more complex?
Sure, do a shell script or something like that.

As long as others can reasonably reproduce your tests, it's fine.

For me, the most critical part of benchmarking a change is deciding what
to test - which queries, data sets, what amounts of data, config, etc.

For example, the data set you used has ~12k rows. Does the behavior
change with 10x or 100x that? It probably does not make sense to go
above available RAM (the I/O costs are likely to make everything else
mostly irrelevant), but CPU caches may matter a lot. Different work_mem
(and maintenance_work_mem) values may be useful too.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2019-06-04 21:33:28 Re: Binary support for pgoutput plugin
Previous Message Peter Eisentraut 2019-06-04 20:58:46 Update list of combining characters