Re: renaming contrib. (was multi-platform, multi-locale regression tests) - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: renaming contrib. (was multi-platform, multi-locale regression tests)
Date
Msg-id 4CDC161D.7010303@dunslane.net
Whole thread Raw
In response to Re: renaming contrib. (was multi-platform, multi-locale regression tests)  (Aidan Van Dyk <aidan@highrise.ca>)
List pgsql-hackers

On 11/11/2010 10:17 AM, Aidan Van Dyk wrote:
>
>> 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"
>
> ;-)
>


Well, I was of course being facetious. But since you mention it, 
Postgres is conservative about its defaults because it's a server. I 
don't think quite the same considerations apply to developer software 
that will be running on a workstation. And Tom's complaint was about 
what he saw as incorrect behavior. Our defaults might hurt performance, 
but I don't think they trade speed for incorrect behavior.

Anyway, revenons à nos moutons.

cheers

andrew


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: renaming contrib. (was multi-platform, multi-locale regression tests)
Next
From: Peter Eisentraut
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Don't unblock SIGQUIT in the SIGQUIT handler This was possibly