On 04/10/2010 12:29 AM, Tom Lane [...@sss.pgh.pa.us] wrote:
Seems a bit off-topic for pgsql-performance,
What would be the appropriate forum?
but anyway: the main
known cause for that is if one of the tables used in the query got
dropped (by another session) just after the query started. Could
Scott Marlowe wrote:
> For 2 sockets Intel rules the roost. I'd imagine AMD's much faster
> bus architecture for >2 sockets would make them the winner, but I
> haven't had a system like that to test, either Intel or AMD.
>
AMD has been getting such poor performance due to the RAM they've been
I've got a sql language function which does a fairly simple select from a
table. If I give it one value, it performs quickly (half a ms). If I give it
another value, it does not (1.1 seconds). When I run the equivalent select
outside of the function, both values perform roughly the same (even th
2010/4/9 Scott Marlowe :
> On Fri, Apr 9, 2010 at 10:30 AM, Merlin Moncure wrote:
>> On Fri, Apr 9, 2010 at 12:03 PM, Greg Smith wrote:
>>> The main problem with this configuration is that work_mem is set to an
>>> unsafe value--1.6GB. With potentially 400 connections and about 2GB of RAM
>>> fr
