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
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) |