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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Aidan Van Dyk <aidan(at)highrise(dot)ca>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Marti Raudsepp <marti(at)juffo(dot)org>, peter_e(at)gmx(dot)net, pgsql-hackers(at)postgresql(dot)org
Subject: Re: renaming contrib. (was multi-platform, multi-locale regression tests)
Date: 2010-11-11 16:13:17
Message-ID: 4CDC161D.7010303@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2010-11-11 16:41:33 Re: wCTE behaviour
Previous Message Tom Lane 2010-11-11 16:08:01 Re: renaming contrib. (was multi-platform, multi-locale regression tests)