[PERFORM] EXPLAIN ANALYZE on 8.2

Hi, everybody! Running the same query on pg 8.2 through EXPLAIN ANALYZE takes 4x-10x time as running it without it. Is it ok? Example: testing= select count(*) from auth_user; count - 2575675 (1 row) Time: 1450,829 ms testing= explain analyze select count(*) from auth_user;

Re: [PERFORM] EXPLAIN ANALYZE on 8.2

: Evgeny Gridasov [EMAIL PROTECTED] writes: Running the same query on pg 8.2 through EXPLAIN ANALYZE takes 4x-10x time as running it without it. If your machine has slow gettimeofday() this is not surprising. 8.2 is no worse (or better) than any prior version. Some quick arithmetic from

Re: [PERFORM] High CPU Load

, -- Evgeny Gridasov Software Engineer I-Free, Russia ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [PERFORM] pg_dump issue

for the nightly backup on both machines: pg_dump -F c -f $DB.backup.$DATE $DB Kind of scratching my head on this one Thank you, Tim McElroy -- Evgeny Gridasov Software Engineer I-Free, Russia ---(end of broadcast)--- TIP 2: Don't 'kill -9

Re: [PERFORM] Help optimizing a slow index scan

)--- TIP 5: don't forget to increase your free space map settings -- Evgeny Gridasov Software Engineer I-Free, Russia ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [PERFORM] Background writer configuration

was during benchmark start. What happens during this period? On Thu, 16 Mar 2006 15:58:53 -0600 Kevin Grittner [EMAIL PROTECTED] wrote: On Thu, Mar 16, 2006 at 12:15 pm, in message [EMAIL PROTECTED], Evgeny Gridasov [EMAIL PROTECTED] wrote: please, could you post other settings from your

Re: [PERFORM] Background writer configuration

. The operating system was Debian Linux, filesystem ext3. Did you use postgres compiled for AMD64 with the 64 kernel, or did you use a 32 bit postgres in emulation mode ? -- Evgeny Gridasov Software Engineer I-Free, Russia ---(end of broadcast

Re: [PERFORM] Background writer configuration

: On 2006-03-17, at 15:50, Evgeny Gridasov wrote: template1=# select version(); version -- --- PostgreSQL 8.1.3 on x86_64-pc-linux-gnu, compiled by GCC cc (GCC

Re: [PERFORM] Background writer configuration

with our web site, which were corrected by adjusting the configuration of the background writer. I'm posting just to provide information which others might find useful -- I don't have any problem I'm trying to solve in this regard. -- Evgeny Gridasov Software Engineer I-Free, Russia

[PERFORM] one-field index vs. multi-field index planner estimates

i2, postgres uses index i3 which is faster than i2 ofcourse. I've noticed that planner estimated all queries for all three cases with the same cost. So, is it a planner bad estimate or what? -- Evgeny Gridasov Software Engineer I-Free, Russia ---(end of broadcast

Re: [PERFORM] one-field index vs. multi-field index planner

Tom, ofcourse I've analyzed it. visible is true for about 0.3% of all rows. testing table contains about 300,000-500,000 rows. On Fri, 10 Mar 2006 12:09:19 -0500 Tom Lane [EMAIL PROTECTED] wrote: Evgeny Gridasov [EMAIL PROTECTED] writes: Recently I've discovered an interesting thing

[PERFORM] wal sync method

Hi everybody! Which wal sync method is the fastest under linux 2.6.x? I'm using RAID-10 (JFS filesystem), 2xXEON, 4 Gb RAM. I've tried to switch to open_sync which seems to work faster than default fdatasync, but is it crash-safe? -- Evgeny Gridasov Software Engineer I-Free, Russia

[PERFORM] DB responce during DB dump

pg_dump output bandwidth, a simple traffic shaper, which runs as: pg_dumpall -c -U postgres | limit_bandwidth.pl | bzip2 pgsql_dump.bz2 The limit_bandwidth.pl script limits pipe output at 4Mb/sec rate, which seems to be ok. Is there any other solution to avoid this problem? -- Evgeny Gridasov

Re: [PERFORM] DB responce during DB dump

throttling logic inside pg_dump itself --- there's still a comment about it in pg_dump.c. The experiment didn't seem very successful, which is why it never got to be a permanent feature. I'm curious to know why this perl script is doing a better job than we were able to do inside pg_dump. -- Evgeny

Re: [PERFORM] DB responce during DB dump

backup? -- Evgeny Gridasov Software Engineer I-Free, Russia ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings

[PERFORM] slow COMMITs

depend upon them. What parameters should I tune? -- Evgeny Gridasov Software Engineer I-Free, Russia ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL

Re: [PERFORM] RAID Stripe size

setting. Am i right ? -- Evgeny Gridasov Software Developer I-Free, Russia ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do

[PERFORM] Planner statistics vs. count(*)

...)? -- Evgeny Gridasov Software Developer I-Free, Russia ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] Performance considerations for very heavy INSERT

Opteron, 16 or more G of RAM, and a fiberchannel hardware raid array or two (~ 1TB available RAID10 storage) with 15krpm disks and battery-backed write cache. -- Evgeny Gridasov Software Developer I-Free, Russia ---(end of broadcast)--- TIP 6: explain