Re: [PERFORM] Performance considerations for very heavy INSERT

uction will hopefully be a 4-8-way > 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 o

Re: [PERFORM] RAID Stripe size

> > Currently the strip size is 8k. I read in many place this is a poor > setting. > > Am i right ? -- Evgeny Gridasov Software Developer I-Free, Russia ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will i

Re: [PERFORM] RAID Stripe size

lternative for a number of reasons. > > richard > > ---(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 not >match -- Evgeny Grid

[PERFORM] Planner statistics vs. count(*)

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

[PERFORM] slow COMMITs

t time does not always 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 co

[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

]> wrote: > 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

[PERFORM] DB responce during DB dump

limit 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

Re: [PERFORM] DB responce during DB dump

ob than we were able to do inside pg_dump. -- 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 PROTECTED] so that y

Re: [PERFORM] DB responce during DB dump

log-shipping or replication (e.g. slony) > to have an off-machine backup? -- Evgeny Gridasov Software Engineer I-Free, Russia ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings

[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-Fr

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

. When I drop index 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 ---

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

Re: [PERFORM] Background writer configuration

s of query timeouts 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. > -- Evg

Re: [PERFORM] Background writer configuration

at I see the same IO which 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

Re: [PERFORM] Background writer configuration

; from default installed i386 userland/amd64 kernel. 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 Softwar

Re: [PERFORM] Background writer configuration

wrote: > On 2006-03-17, at 15:50, Evgeny Gridasov wrote: > > > template1=# select version(); > >version > > -- > > --- > > Postgre

Re: [PERFORM] Help optimizing a slow index scan

"gist" > HINT: You must specify an operator class for the index or define a > default operator class for the data type. > > I'm not sure what a "default operator class" is, exactly.. > > -Dan > > ---(end of broadcast)--

Re: [PERFORM] pg_dump issue

uestion; has anyone run into a similar issue? Here is the command I use > 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 > > -

Re: [PERFORM] High CPU Load

f the query results are the same and maybe the query will execute > > faster. > > Thanks for your advice, but the load was good with previous version of > postgres -> 7.4.6 on the same server and same datas, same application, > same final users ... > > So we supect some system parameter, but which ? > > With vmstat -s is showing a lot of "pages swapped out", have you an > idea ? > > Thanls a lot, -- Evgeny Gridasov Software Engineer I-Free, Russia ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster