Re: renaming contrib. (was multi-platform, multi-locale regression tests)

On Thu, Nov 11, 2010 at 8:28 AM, Andrew Dunstan <andrew@dunslane.net> wrote:

>> It's intentional behavior.  It gives up when there are too many
>> differences to avoid being slow.

And, it's configurable, at least to diff and merge.  If it's not
available in all the other porcelains, yes, that would be bugs that
should be fixed:      -l<num>          The -M and -C options require O(n^2) processing time where
n is the number of potential          rename/copy targets. This option prevents rename/copy
detection from running if the number          of rename/copy targets exceeds the specified number.

And can even be specified as config options diff.renameLimit and
merge.renameLimit.

> We should adopt that philosophy. I suggest we limit all tables in future to
> 1m rows in the interests of speed.

As long as it's configurable, and if it would make operations on
smaller tables faster, than go for it.

And we should by defualt limit shared_buffers to 32MB.  Oh wait.

There are always tradeoffs when picking defaults, a-la-postgresql.conf.

We as a community are generally pretty quick to pick up the "defaults
are very conservative, make sure you tune ..." song when people
complain about "pg being too slow"

;-)

a.

--
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.