Hi!
-Ursprüngliche Nachricht-
Von: Tom Lane [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 4. Dezember 2005 19:32
An: Markus Wollny
Cc: pgsql-performance@postgresql.org
Betreff: Re: [PERFORM] Queries taking ages in PG 8.1, have
been much faster in PG=8.0
The data is not quite
Rick Schumeyer wrote:
1) the input data file
2) the pg table
3) the WAL
And journal of file system, especially if you not set noatime mount
option. WAL and file system journal like to make sync.
IMHO: on first disk (raid mirror:)) I place /, pg_table and file system
Markus Wollny [EMAIL PROTECTED] writes:
... What I find interesting though is
that the plain index scan in 8.0 is so enormously cheaper
than it's estimated to be. Perhaps the answer table in your
8.0 installation is almost perfectly ordered by session_id?
Not quite - there may be several
-Ursprüngliche Nachricht-
Von: Tom Lane [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 5. Dezember 2005 15:33
An: Markus Wollny
Cc: pgsql-performance@postgresql.org
Betreff: Re: AW: [PERFORM] Queries taking ages in PG 8.1,
have been much faster in PG=8.0
Could we see the
Olleg Samoylov [EMAIL PROTECTED] writes:
I try to test this. Linux, memory page 4kb, disk page 4kb. I set BLCKSZ
to 4kb. I get some performance improve, but not big, may be because I
have 4Gb on test server (amd64).
It's highly unlikely that reducing BLCKSZ is a good idea. There are bad
Markus Wollny [EMAIL PROTECTED] writes:
Could we see the pg_stats row for answer.session_id in both
8.0 and 8.1?
Here you are:
8.1:
Correlation -0.0736492
8.0.3:
Correlation -0.237136
Interesting --- if the 8.1 database is a dump and restore of the 8.0,
you'd expect
-Ursprüngliche Nachricht-
Von: Tom Lane [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 5. Dezember 2005 16:12
An: Markus Wollny
Cc: pgsql-performance@postgresql.org
Betreff: Re: AW: AW: [PERFORM] Queries taking ages in PG 8.1,
have been much faster in PG=8.0
Markus Wollny [EMAIL
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag
von Markus Wollny
Gesendet: Montag, 5. Dezember 2005 16:41
An: Tom Lane
Cc: pgsql-performance@postgresql.org
Betreff: Re: [PERFORM] Queries taking ages in PG 8.1, have
been much faster in
Ron wrote:
At 01:58 PM 12/2/2005, Rick Schumeyer wrote:
I installed another drive in my linux pc in an attempt to improve
performance
on a large COPY to a table with a geometry index.
Based on previous discussion, it seems there are three things
competing for the hard drive:
1) the
On Mon, 5 Dec 2005, Thomas Harold wrote:
(noob question incoming)
Section 26.4 WAL Internals
http://www.postgresql.org/docs/8.1/interactive/wal-internals.html
This seems to be the applicable chapter. They talk about creating a symlink
for the data/pg_xlog folder to point at another disk
David Lang wrote:
the application can' tell the difference, but the reason for seperating
them isn't for the application, it's so that different pieces of
hardware can work on different things without having to bounce back and
forth between them.
useing the same drives with LVM doesn't
Hello Bernd Jagla,
Are you the Bernd from Berlin? I am looking for you and found your name on the internet. Would you please contact me?
Mirjam Tilstra
Sent from the PostgreSQL - performance forum at Nabble.com:
Re: Best hardware
Hi,
I'm using PostgreSQL
8.0.3 on Linux RedHat WS 3.0.
My application
updates counters in DB. I left a test over the night that increased counter of
specific record. After night running (several hundreds of thousands updates), I
found out that the time spent on UPDATE increased to be more
On Mon, Dec 05, 2005 at 19:05:01 +0200,
Assaf Yaari [EMAIL PROTECTED] wrote:
Hi,
I'm using PostgreSQL 8.0.3 on Linux RedHat WS 3.0.
My application updates counters in DB. I left a test over the night that
increased counter of specific record. After night running (several
hundreds of
I have a case where an outer join's taking 10X more time than
a non-outer join; and it looks to me like the outer join could
have taken advantage of the same indexes that the non-outer join did.
In both cases, the outermost thing is a nested loop. The
top subplan gets all point features whre
Tom Lane wrote:
Olleg Samoylov [EMAIL PROTECTED] writes:
I try to test this. Linux, memory page 4kb, disk page 4kb. I set BLCKSZ
to 4kb. I get some performance improve, but not big, may be because I
have 4Gb on test server (amd64).
It's highly unlikely that reducing BLCKSZ is a good idea.
[EMAIL PROTECTED] writes:
In both cases, the outermost thing is a nested loop. The
top subplan gets all point features whre featureid=120.
The outer join did not use an index for this.
The non-outer join did use an index for this.
Hm, I can't duplicate this in a simple test (see below).
On Mon, 5 Dec 2005, Tom Lane wrote:
Hm, I can't duplicate this in a simple test...
Can you try updating to 8.1 branch tip ...
Actually, a quick and dirty thing would be to try my would-be test case
below, and see if you get a seqscan on your copy.
With your simple test-case I did not get
Olleg wrote:
I test performace on database test server. This is copy of working
billing system to test new features and experiments. Test task was one
day traffic log. Average time of a one test was 260 minutes. Postgresql
7.4.8. Server dual Opteron 240, 4Gb RAM.
Did you execute queries
At 04:32 PM 12/5/2005, Olleg wrote:
Tom Lane wrote:
Olleg Samoylov [EMAIL PROTECTED] writes:
I try to test this. Linux, memory page 4kb, disk page 4kb. I set
BLCKSZ to 4kb. I get some performance improve, but not big, may be
because I have 4Gb on test server (amd64).
It's highly unlikely
On 12/4/2005 4:33 AM, Michael Riess wrote:
I will do the following:
- switch to 10k buffers on a 1GB machine, 20k buffers on a 2GB machine
- try to optimize my connection polls to remember which apps (groups of
30 tables) were accessed, so that there is a better chance of using caches
- swap
On Mon, 5 Dec 2005, Thomas Harold wrote:
Yeah, I don't think I was clear about the config. It's (4) disks setup as a
pair of RAID1 sets. My original config was pgsql on the first RAID set (data
and WAL). I'm now experimenting with putting the data/pg_xlog folder on the
2nd set of disks.
Ron [EMAIL PROTECTED] writes:
Where? BLCKSZ as large as 64KB has been shown to improve
performance.
Not in the Postgres context, because you can't set BLCKSZ higher than
32K without doing extensive surgery on the page item pointer layout.
If anyone's actually gone to that much trouble, they
David Lang wrote:
in that case you logicly have two disks, so see the post from Ron
earlier in this thread.
And it's a very nice performance gain. Percent spent waiting according
to top is down around 10-20% instead of 80-90%. While I'm not
prepared to benchmark, database performance is
24 matches
Mail list logo
