Christopher Petrilli <[EMAIL PROTECTED]> writes:
> On 7/18/05, Tom Lane <[EMAIL PROTECTED]> wrote:
>> I have no idea at all what's causing the sudden falloff in performance
>> after about 1 iterations. COPY per se ought to be about a
>> constant-time operation, since APPEND is (or should be) c
You might want to set join_collapse_limit high, and use the JOIN
operators rather than the comma-separated lists. We generate the WHERE
clause on the fly, based on user input, and this has worked well for us.
-Kevin
>>> "Dario" <[EMAIL PROTECTED]> 07/18/05 2:24 PM >>>
Hi.
> Just out of curi
On 7/18/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Christopher Petrilli <[EMAIL PROTECTED]> writes:
> > On 7/18/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> I have no idea at all what's causing the sudden falloff in performance
> >> after about 1 iterations. COPY per se ought to be about a
> >>
Hi.
> Just out of curiosity, does it do any better with the following?
>
>SELECT ...
Yes, it does.
But my query could also be
SELECT ...
FROM a
JOIN b ON (a.key = b.key)
LEFT JOIN c ON (c.key = a.key)
LEFT JOIN d ON (d.key=a.key)
/*new*/ , e
WHERE (b.column <= 10
In regards to
http://archives.postgresql.org/pgsql-performance/2005-07/msg00261.php
Tom Says:
> ... as indeed it does according to Robert's recent reports. Still
> awaiting the definitive test, but I'm starting to think this is another
> case of the strange behavior Ian Westmacott exhibited.
Ok
Christopher Petrilli <[EMAIL PROTECTED]> writes:
> http://blog.amber.org/diagrams/comparison_mysql_pgsql.png
> Notice the VERY steep drop off.
Hmm. Whatever that is, it's not checkpoint's fault. I would interpret
the regular upticks in the Postgres times (every several hundred
iterations) as be
Robert Creager <[EMAIL PROTECTED]> writes:
> Around 8:15 I was starting to receive hits of a few seconds of high CS hits,
> higher than the previous 7 hour run on 741. I changed the vacuum delay to 0
> and
> HUP'ed the server (how can I see the value vacuum_cost_delay run
> time?).
Start a fresh
Hi,
Suppose I have a table with 4 fields (f1, f2, f3, f4)
I define 2 unique indexes u1 (f1, f2, f3) and u2 (f1, f2, f4)
I have 3 records
A, B, C, D (this will be inserted)
A, B, C, E (this will pass u2, but not u1, thus not inserted)
A, B, F, D (this will pass u1, but not u2, thus not inserted)
On 7/18/05, Vivek Khera <[EMAIL PROTECTED]> wrote:
>
> On Jul 17, 2005, at 1:08 PM, Christopher Petrilli wrote:
>
> > Normally, checkpoint_segments can help absorb some of that, but my
> > experience is that if I crank the number up, it simply delays the
> > impact, and when it occurs, it takes a
On Mon, 18 Jul 2005 13:52:53 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Start a fresh psql session and "SHOW vacuum_cost_delay" to verify what
> the active setting is.
Thanks. It does show 0 for 803 in a session that was up since I thought I had
HUPed the server with the new value.
This is lea
On Jul 17, 2005, at 1:08 PM, Christopher Petrilli wrote:
Normally, checkpoint_segments can help absorb some of that, but my
experience is that if I crank the number up, it simply delays the
impact, and when it occurs, it takes a VERY long time (minutes) to
clear.
There comes a point where you
On 7/18/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Christopher Petrilli <[EMAIL PROTECTED]> writes:
> > http://blog.amber.org/diagrams/comparison_mysql_pgsql.png
>
> > Notice the VERY steep drop off.
>
> Hmm. Whatever that is, it's not checkpoint's fault. I would interpret
> the regular upticks
Just out of curiosity, does it do any better with the following?
SELECT ...
FROM a
JOIN b ON (a.key = b.key)
LEFT JOIN c ON (c.key = a.key)
LEFT JOIN d ON (d.key=a.key)
WHERE (b.column <= 100)
>>> "Dario Pudlo" <[EMAIL PROTECTED]> 07/06/05 4:54 PM >>>
(first at all,
"Matthew T. O'Connor" writes:
> Therefore (if you aren't specifying them from the command line), on 803,
> the vacuum delay settings should be the same for a cron issued vacuum
> and an autovacuum issued vacuum. So if the vacuum delay settings are
> the problem, then it should show up either w
Tom Lane wrote:
Robert Creager <[EMAIL PROTECTED]> writes:
I've "vacuum_cost_delay = 10" in the conf file for 803.
Hmm, did you read this thread?
http://archives.postgresql.org/pgsql-performance/2005-07/msg00088.php
It's still far from clear what's going on there, but it might be
int
Robert Creager <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> confessed:
>> It's still far from clear what's going on there, but it might be
>> interesting to see if turning off the vacuum delay changes your results
>> with 8.0.
> Can that be affected by hupping the server, or do I nee
When grilled further on (Mon, 18 Jul 2005 09:23:11 -0400),
Tom Lane <[EMAIL PROTECTED]> confessed:
> It's still far from clear what's going on there, but it might be
> interesting to see if turning off the vacuum delay changes your results
> with 8.0.
>
Can that be affected by hupping the server
When grilled further on (Mon, 18 Jul 2005 00:10:53 -0400),
Tom Lane <[EMAIL PROTECTED]> confessed:
> The context swap problem was no worse in 8.0 than in prior versions,
> so that hardly seems like a good explanation. Have you tried reverting
> to the cron-based vacuuming method you used in 7.4?
Robert Creager <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> confessed:
>> The context swap problem was no worse in 8.0 than in prior versions,
>> so that hardly seems like a good explanation. Have you tried reverting
>> to the cron-based vacuuming method you used in 7.4?
> I've "vac
On 7/15/05, Bruno Wolff III <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 14, 2005 at 16:29:58 -0600,
> Dan Harris <[EMAIL PROTECTED]> wrote:
> >
> > Ok, I tried this one. My ssh keeps getting cut off by a router
> > somewhere between me and the server due to inactivity timeouts, so
> > all I know is
20 matches
Mail list logo
