all. Much appreciated.
Cheers.
On Wednesday 21 June 2006 19:11, Jim C. Nasby wrote:
> On Wed, Jun 21, 2006 at 04:41:45PM -0300, jody brownell wrote:
> > BTW, in production with a similar load - autovacuum with default out of the
> > box
> > settings seems to work quite
BTW, in production with a similar load - autovacuum with default out of the box
settings seems to work quite well
I double checked this earlier today.
On Wednesday 21 June 2006 16:38, Jim C. Nasby wrote:
> 5
---(end of broadcast)---
TIP 5: do
OK this was over a 12 - 16 hour period of not having anything done with it
though right?
I am assuming if autovacuum were active through out that period, we would be
somewhat better off ...is that not accurate?
On Wednesday 21 June 2006 16:38, Jim C. Nasby wrote:
> 5
-
block and row are always configured on - they are my friend :)
thanks
On Wednesday 21 June 2006 13:44, Csaba Nagy wrote:
> On Wed, 2006-06-21 at 18:39, jody brownell wrote:
> > that is exactly what I am seeing, one process, no change, always in idle
> > while the others
:21, jody brownell wrote:
> > That is interesting.
> >
> > There is one thread keeping a transaction open it appears from ps
> >
> > postgres: app app xxx(42644) idle in transaction
>
> That shouldn't be a problem on itself, "idle in transaction"
l track it
down and see what the difference is.
thanks
On Wednesday 21 June 2006 13:21, jody brownell wrote:
> That is interesting.
>
> There is one thread keeping a transaction open it appears from ps
>
> postgres: app app xxx(42644) idle in transaction
>
> however, I created
try a 30 second naptime, if this is it, that should increase the likely
hood of falling on the right side of the TX more often.
make sense?
On Wednesday 21 June 2006 12:42, Csaba Nagy wrote:
> On Wed, 2006-06-21 at 17:27, jody brownell wrote:
> > Our application is broken down quite well.
Our application is broken down quite well. We have two main writing processes
writing to two separate sets of tables. No crossing over, nothign to prohibit
the
vacuuming in the nature which you describe.
My longest transaction on the tables in question are typically quite short
until
of cours
Hey - I am running into a data relation bloat problem which I believe is
causing fairly significant
slowdown of my updates. I am using version
version
-
PostgreSQL 8.1.4 on i586-trusti
this may be painful :(
I will modify the routine to help isolate the problem. stay tuned.
BTW - the fix you mentioned is that targeted for 8.2? Is there a timeline
for 8.2?
On Thursday 15 June 2006 12:44, Tom Lane wrote:
> "jody brownell" <[EMAIL PROTECTED]> wr
resolves
it for now. If not, I will write
a java app, stored procedure (table etc) reproduce it without our application.
Oh yeah, it is when I use about have of my swap, dstat starts reporting heavy
paging, memory climbs very quickly.
On Thursday 15 June 2006 09:15, jody brownell wrote:
>
The last version of postgres we had in production was 8.1.1 actually, not
8.1.3.
So far, on my stability box and older production stability boxes I dont see the
same behavior.
I will install 8.1.1 on these boxes and see what I see.
On Thursday 15 June 2006 09:01, jody brownell wrote
unique_violation THEN
-- do nothing... app cache may be out of date.
END;
END LOOP;
RETURN v_returns;
END;
$body$
LANGUAGE plpgsql VOLATILE CALLED ON NULL INPUT SECURITY INVOKER;
On Wednesday 14 June 2006 17:03, you wrote:
> "jody brownell" <
I have a box with an app and postgresql on it. Hardware includes with 2 2.8 Ghz
xeons 512KB cache, 4 GB of memory, 6 scsi disk in a software
raid 5 on a trustix 2.2 with a 2.6.15.3 kernel. The data and indexes are on the
raid array while the tx log is on disk
with the OS. All is well.
The one
14 matches
Mail list logo
