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

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: renaming contrib. (was multi-platform, multi-locale regression tests)
Дата
Msg-id 4CDC161D.7010303@dunslane.net
обсуждение исходный текст
Ответ на Re: renaming contrib. (was multi-platform, multi-locale regression tests)  (Aidan Van Dyk <aidan@highrise.ca>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: renaming contrib. (was multi-platform, multi-locale regression tests)
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Don't unblock SIGQUIT in the SIGQUIT handler This was possibly