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 question
> 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
> micro
while you weren't looking, Tom Lane wrote:
> What's not immediately evident is whether the excess I/O accounted for
> all of the slowdown. Could you retry the strace with -r and -T options
> so we can see how much time is being spent inside and outside the
> syscalls?
Unlike the previous run (th
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
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?
No
Andrew Sullivan wrote:
Sorry I haven't had a chance to reply to this sooner.
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
Arthur Ward wrote:
Jan's vacuum-delay-only patch that nobody can find is here:
http://archives.postgresql.org/pgsql-hackers/2003-11/msg00518.php
I've been using it in testing & production without any problems.
Great to know -- many thanks.
I've hacked my own vacuum-delay-only patch form Jan's al
"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
while you weren't looking, Tom Lane wrote:
> I hate to break it to you, but that most definitely means you are
> running with BLCKSZ = 32K. Whatever you thought you were rebuilding
> didn't take effect.
I saw that and thought so. The other day, I was rooting around in
$PGDATA, and saw a lot of
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
"Rosser Schwarz" <[EMAIL PROTECTED]> writes:
>> 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.
"select version()" is t
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
nec
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) );
CREATE TABLE TEST_2 (
F1 VARCHAR(10),
F2 VARCHAR(10) );
we're c
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 VARCHA
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 TABL
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'v
16 matches
Mail list logo
