On Fri, Oct 31, 2008 at 4:14 PM, David Rees <[EMAIL PROTECTED]> wrote:
> Well, I'm pretty sure the delays are not checkpoint related. None of
> the slow commits line up at all with the end of checkpoints.
>
> The period of high delays occur during the same period of time each
> week, but it's not d
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> I'm trying to quantify the issue, and would appreciate any
> suggestions, either for mitigation or collecting useful data to find
> the cause of the performance regression. I create a script which
> brackets 1000 lines like the following within a sing
>>> "Kevin Grittner" <[EMAIL PROTECTED]> wrote:
> I'm going to get the latest snapshot to see if the issue has changed
> for 8.4devel
In testing under today's snapshot, it seemed to take 150,000 writes to
create and drop 1,000 temporary tables within a database transaction.
The numbers for the
I'll have to think a bit about that given that the query had run for 20
hours of 250MB/sec-ish disk reads and wasn't done. Luckily, thats not even
35% disk utilization on this system, and the 'right' query with fewer tables
does things properly with a hash and takes seconds rather than hours
(days
"Scott Carey" <[EMAIL PROTECTED]> writes:
> Certainly, a cost estimate that is ... LESS than one of the sub sections of
> the query is wrong. This was one hell of a broken query, but it at least
> should have taken an approach that was not a nested loop, and I'm curious if
> that choice was due
On Wed, 5 Nov 2008, Peter Schuller wrote:
In addition, PostgreSQL is not even close to even filling it's buffer
cache. The buffer cache is configured at 1 GB, and the resident size
of the PostgreSQL process is only 80-90 MB so far. So even
independently of any lru multplier setting, delays and w
So, we had a query run accidentally without going through the right checks
to ensure that it had the right limits in a where clause for our table
partitioning, resulting in an attempt to scan TB's of data.
Obviously, we fixed the query, but the curious result is this explain plan
(shortened, in fu
>>> "Kevin Grittner" <[EMAIL PROTECTED]> wrote:
> We have found one area where jobs are running
> much longer and having a greater impact on concurrent jobs -- those
> where the programmer creates and drops many temporary tables
> (thousands) within a database transaction.
I forgot to include th
We recently upgraded the databases for our circuit court applications
from PostgreSQL 8.2.5 to 8.3.4. The application software didn't
change. Most software runs fine, and our benchmarks prior to the
update tended to show a measurable, if not dramatic, performance
improvement overall. We have fou
On Wed, 2008-11-05 at 13:12 +0200, Віталій Тимчишин wrote:
> For a long time already I can see very poor OR performance in
> postgres.
> If one have query like "select something from table where condition1
> or condition2" it may take ages to execute while
> "select something from table where cond
"=?ISO-8859-5?B?svbi0Nv22SDC2Nzn2OjY3Q==?=" <[EMAIL PROTECTED]> writes:
> For a long time already I can see very poor OR performance in postgres.
If you would provide a concrete example rather than handwaving, we might
be able to offer some advice ...
regards, tom lane
--
Hello,
I've had the feeling for a while that the pg_stat_bgwriter statistics
doesn't work quite the way I have understood it (based on the
excellent [1] and the pg docs).
I am now monitoring a database that has an lru_multiplier of 4.0, a
delay of 200ms and a maxpages of 1000. Current stats:
pos
Hello.
For a long time already I can see very poor OR performance in postgres.
If one have query like "select something from table where condition1 or
condition2" it may take ages to execute while
"select something from table where condition1" and "select something from
table where condition2" are
13 matches
Mail list logo
