Re: [PERFORM] atrocious update performance

2004-03-17 Thread Richard Huxton
On Tuesday 16 March 2004 00:08, Tom Lane wrote: I'm inclined to suspect an issue with foreign-key checking. You didn't give us any details about foreign key relationships your cust table is involved in --- could we see those? And the schemas of the other tables involved? Two questions Tom:

Re: [PERFORM] rapid degradation after postmaster restart

2004-03-17 Thread Arthur Ward
The problem with Jan's more complex version of the patch (at least the one I found - perhaps not the right one) is it includes a bunch of other experimental stuff that I'd not want to mess with at the moment. Would changing the input units (for the original patch) from milli-secs to

Re: [PERFORM] rapid degradation after postmaster restart

2004-03-17 Thread Andrew Sullivan
Sorry I haven't had a chance to reply to this sooner. On Fri, Mar 12, 2004 at 05:38:37PM -0800, Joe Conway wrote: The problem is this: the application runs an insert, that fires off a trigger, that cascades into a fairly complex series of functions, that do a bunch of calculations, inserts,

Re: [PERFORM] atrocious update performance

2004-03-17 Thread Rosser Schwarz
while you weren't looking, Tom Lane wrote: Hm. It looks like you mistakenly traced psql rather than the backend, but since the delay went away we wouldn't have learned anything anyhow. Have you got any idea what conditions may have changed between seeing delay and not seeing delay? None,

Re: [PERFORM] atrocious update performance

2004-03-17 Thread Tom Lane
Rosser Schwarz [EMAIL PROTECTED] writes: while you weren't looking, Tom Lane wrote: Have you got any idea what conditions may have changed between seeing delay and not seeing delay? None, offhand. I have noticed that when a large query is running, the machine can sporadically just

Re: [PERFORM] atrocious update performance

2004-03-17 Thread Rosser Schwarz
I wrote: Regardless, something thinks it's still there. Is there any way that it is, and that I've somehow been running 7.3.2 all along? `which psql`, c show the bindir from my configure, but I'm not sure that's sufficient. The weird thing is that I know I never built 7.3.anything with 32K

Re: [PERFORM] rapid degradation after postmaster restart

2004-03-17 Thread Matthew T. O'Connor
Andrew Sullivan wrote: The vacuum delay stuff that you're working on may help, but I can't really believe it's your salvation if this is happening after only a few minutes. No matter how much you're doing inside those functions, you surely can't be causing so many dead tuples that a vacuum is

Re: [PERFORM] PostgreSQL Disk Usage and Page Size

2004-03-17 Thread Stephen Robert Norris
On Thu, 2004-03-18 at 10:52, Seum-Lim Gan wrote: Hi all, we have a question about the pagesize in PostgreSQL: Using different pagesizes: 4K, 8K, 16K, 32K, when we store different record sizes such as in the following example: CREATE TABLE TEST_1 ( F1 VARCHAR(10), F2 VARCHAR(5) );

Re: [PERFORM] PostgreSQL Disk Usage and Page Size

2004-03-17 Thread Stephan Szabo
On Wed, 17 Mar 2004, Seum-Lim Gan wrote: we have a question about the pagesize in PostgreSQL: Using different pagesizes: 4K, 8K, 16K, 32K, when we store different record sizes such as in the following example: CREATE TABLE TEST_1 ( F1 VARCHAR(10), F2 VARCHAR(5) ); CREATE TABLE TEST_2 (

Re: [PERFORM] severe performance issue with planner (fwd)

2004-03-17 Thread Tom Lane
Kris Jurka [EMAIL PROTECTED] writes: On Thu, 11 Mar 2004, Tom Lane wrote: Eric Brown [EMAIL PROTECTED] writes: [ planning a 9-table query takes too long ] See http://www.postgresql.org/docs/7.4/static/explicit-joins.html for some useful tips. Is this the best answer we've got? For me