2nd part of table descriptions
Table "public.company"
Column|Type | Modifiers
--+-+
id | integer | not null
Query and first part of the table descriptions
Query:
explain analyze
select distinct on
(t8.id) t8.id,
t8.payment_id,
t8.amount_id,
t8.active,
t8.or
On Tue, Mar 3, 2009 at 5:34 PM, Tom Lane wrote:
> Comparisons on
> numerics aren't terribly fast though (in either release). I wonder
> whether you could change the key columns to int or bigint.
I changed the affected columns from numeric to integers and I was unable to
get any performance gai
On Wed, Mar 4, 2009 at 11:18 AM, Scott Carey wrote:
> You may have decreased performance in your batch jobs with the lower
> work_mem setting.
That would be why I recommended benchmarking queries that need more
memory and setting work_mem for those queries alone.
> Additionally, the fact that yo
You may have decreased performance in your batch jobs with the lower work_mem
setting.
Additionally, the fact that you haven't had swap storm issues so far means that
although there is certain risk of an issue, its probably a lot lower than what
has been talked about here so far.
Without a chang
Running PG 8.1.11 on AIX 5.3
Trying to track down the cause of long running commits on one of our DB
servers.
I can rule checkpoints out (I've set log_min_messages to debug2 and the commits
are not happening during checkpoints).
We have this problem over a period of ~ 35 minutes per day only
- "Scott Marlowe" escreveu:
> Oh my lord, that is a foot gun waiting to go off. Assuming 2k
> connections, and somehow a fair number of them went active with big
> sorts, you'd be able to exhaust all physical memory with about 8 to
> 16 connections. Lower work_mem now. To something like 1
Hi,
On Wednesday 04 March 2009 02:37:42 Scott Marlowe wrote:
> If some oddball query really needs a lot of work_mem,
> and benchmarks show something larger work_mem helps, consider raising
> the work_mem setting for that one query to something under 1G (way
> under 1G) That makes it noticeably fas
