Re: [PERFORM] Presentation

On Wed, 8 Oct 2003, Neil Conway wrote: > On Wed, 2003-10-08 at 11:02, Jeff wrote: > > The boss cleared my de-company info-ified pg presentation. > > Slide 37: as far as I know, reordering of outer joins is not implemented > in 7.4 > Huh. I could have sworn Tom did something

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

ompiled telling you it will only run on ultrasparc machines) -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an ind

Re: [PERFORM] Sun performance - Major discovery!

On Wed, 8 Oct 2003, Neil Conway wrote: > Hey Jeff, > > On Wed, 2003-10-08 at 11:46, Jeff wrote: > > Yeah - like I expected it was able to generate much better code for > > _bt_checkkeys which was the #1 function in gcc on both sun & linux. > > If you get a minute,

Re: [PERFORM] Sun performance - Major discovery!

and then various other type mismatches here and there. I skimmed through the manpage.. it doesn't look like we can supress these.. Not sure we want it to look like we have bad code if someone uses cc. perhaps issue a ./configure notice or something? gcc compiles things fine. --

Re: [PERFORM] Sun performance - Major discovery!

On Thu, 9 Oct 2003, Bruce Momjian wrote: > > What is the performance win for the -fast flag again? > > --- > 52 seconds to 19-20 seconds -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http

Re: [PERFORM] Sun performance - Major discovery!

use for the platform that is doing the compile. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] Sun performance - Major discovery!

On Thu, 9 Oct 2003, Kenneth Marshall wrote: > Jeff, > > My first concern with the -fast option is that it makes an executable > that is specific for the platform on which the compilation is run > unless other flags are given. My second concern is the effect it has > on I

Re: [PERFORM] PostgreSQL vs MySQL

year) about fixing bugs that cause horrific corruption. That doesn't make me feel comfy. Remember - in reality InnoDB is still very new. The PG stuff has been tinkered with for years. I like innovation and new things, but in some cases, I prefer the old code that has been looked at for

Re: [PERFORM] Sun performance - Major discovery!

We're keeping the -O2 for gcc in the template and moving the mention of -fast to the FAQ, correct? -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 6: Have you search

[PERFORM] backup/restore - another area.

ow it is - it has a fast backup & fast restore that does essentially #2 and then it has export/import options (works like our current pg_dump and restore). and oh yeah -I've tried disabling fsync on load and while it did go faster it was only 2 minutes faster (9m vs 11m). Any t

Re: [PERFORM] backup/restore - another area.

r, you'll need the logical export. > Yeah, a pg_dump now and then would be useful (and safe). If you wanted to get fancy schmancy you could take the snapshot, archive it, transfer it and unarchive it on machine B. (We actually used to do that here until machine B no longer had the cap

Re: [PERFORM] One or more processor ?

would be used. Check the -HACKERS archives for lengthy discussions of this. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, pl

Re: [PERFORM] PostgreSQL Scalable ?

ry backed write caches seem to be popular). You should also look at how much data this guy will hold, what is the read/write ratio and all the "normal" things you should do while planning a db. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuart

Re: [PERFORM] backup/restore - another area.

you are essentially simulating a power failure to PG. Luckly the WAL works like a champ. Also, these backups can be much larger since it has to include the indexes as well. but this is a price you have to pay. I did have some initial problems with snapshots & corruption but it turned out to be us

Re: [PERFORM] backup/restore - another area.

On Thu, 16 Oct 2003 09:49:59 -0700 Josh Berkus <[EMAIL PROTECTED]> wrote: > Jeff, > > > The downside is > > this method will only work on that specific version of PG and it > > isn't the"cleanest" thing in the world since you are essentially > &g

Re: [PERFORM] backup/restore - another area.

On Thu, 16 Oct 2003 10:09:27 -0700 Josh Berkus <[EMAIL PROTECTED]> wrote: > Jeff, > > > I left the DB up while doing this. > > > > Even had a program sitting around committing data to try and corrupt > > things. (Which is how I discovered I was doing th

Re: [PERFORM] PostgreSQL data on a NAS device ?

post- If you don't mind refurb disks(or slightly used) check out ebay - you can get scsi disks by the truckload for cheap. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] Low Insert/Update Performance

you. Also, if you could provide explain analyze of each query it would be even more helpful! -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 6: Have you searched our list

Re: [PERFORM] Tuning for mid-size server

de. If you check out hte linux-kernel archives you'll see one of the things often recommended when things go odd is to turn off HIMEM support. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)-

[PERFORM] More info in explain analyze

ost by avoiding that spill at a low cost. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nom

[PERFORM] Adding foreign key performance

add the functionality to pg_restore? ie, pg_restore -s 256MB mybackup.db? It would just end up issuing a set sort_mem=256000.. What do you guys think? -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--

Re: [PERFORM] Adding foreign key performance

On Tue, 28 Oct 2003 09:16:45 -0500 Jeff <[EMAIL PROTECTED]> wrote: > 7.3.4: 328912ms [cpu pegged] > 7.4b4: 298383ms [cpu pegged] > Just loaded up delicious 7.4b5 and wow... sort_mem 8192: 137038ms [lots of tmp file activity] sort_mem 256000: 83109ms That's some good wo

Re: [PERFORM] Adding foreign key performance

saturate the IO so once I get more disks in here it should hopefully speed up. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 6: Have you searched our list

Re: [PERFORM] Adding foreign key performance

ular dumps - at the end is a pile of alter table's that create the indices, FK's and triggers. Is the -Fc method different? -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)-

Re: [PERFORM] Adding foreign key performance

regardless so the stats are rather useless. Perhaps in other scenarios it would help. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire

Re: [PERFORM] Pg+Linux swap use

what is running. Perhaps X is running gobbling up your precious mem. But still.. with 1GB there should be virtually no swap activity. How busy is the DB? How many connections? and is sort_mem set high? -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/

Re: [PERFORM] Pg+Linux swap use

m is the guy is seeing swapping.. I'm guessing RH is running some useless stuff in the BG.. or maybe he's running a retarded kernel... or.. maybe.. just.. maybe.. little elves are doing it. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ --

Re: [PERFORM] Value of Quad vs. Dual Processor machine

It really loves those things. good luck -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] INSERT extremely slow with large data sets (fwd)

y foreign keys 2. are these inserts batched into transactions 3. CPU usage? 4. OS? 5. PG config? [shared_buffers, effective_cache_size, etc] 6. IO saturation? Also, try searching the archives. lots of juicy info there too. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftro

Re: [PERFORM] design question: general db performance

malizing can help. But I don't think it is going to be a magical bullet that will make the DB instantly fast. It will reduce the size of it though. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)

Re: [PERFORM] Dump restoration via archive files

back on after your restore!) cna give you some nice speed increases. 4. If you are not using 7.4 and using pg_dump, there isn't much you can do about adding foreign keys going stupidly slow :( -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ -

Re: [PERFORM] tuning questions

ery, but perhaps the sort of those 6000 rows is spilling to disk? If you look in explain analyze you'll see in the "Sort" step(s) it will tell you how many rows and how "wide" they are. If rows * width > sort_mem, it will have to spill the sort to disk, which is slow.

Re: [PERFORM] Slow UPADTE, compared to INSERT

on update. Am i doing something wrong or is this normal? > Remember, UPDATE has to do all the work of select and more. And if you have 4 indexes those will also add to the time (Since it has to update/add them to the tree) -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com

Re: [PERFORM] Solaris Performance (Again)

default and was a huge part of the slowness of PG on solaris. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate

Re: [PERFORM] Performance problems with a higher number of clients

lso consider an OS that deals with that situation a bit better. good luck. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] Index creation

e first place. > > Also, there doesn't seem to be a simple way to disable/recreate all > indexes for a specific table short of explicitely dropping and later > recreating each index? Before creating your index bump up your sort_mem high. set sort_mem = 64000 create index foo on

Re: [PERFORM] [pgsql-advocacy] MySQL+InnoDB vs. PostgreSQL test?

n someday and let it finish loading. Remember - you cannot judge mysql by since connection performance - you can't beat it. But just add up the concurrency and watch the cookies tumble -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ -

Re: [PERFORM] [pgsql-advocacy] MySQL+InnoDB vs. PostgreSQL test?

e a bit of work to get the machine up and running. I don't have time right now to do further testing. However, you could try it out. Not sure at what point it will topple, in my case it didn't matter if it ran good with 5 clients as I'll always have many more clients tha

Re: [PERFORM] [pgsql-advocacy] MySQL+InnoDB vs. PostgreSQL test?

On Tue, 03 Feb 2004 11:46:05 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: > Jeff <[EMAIL PROTECTED]> writes: > > Not sure at what point it will topple, in my case it didn't matter > > if it ran good with 5 clients as I'll always have many more clients &g

Re: [PERFORM] Database conversion woes...

elete|insert's / second (sustained throughout the day. It bursts up to 150 now and then). And we're doing about 40 selects / second. And the machine it is running on is typically 95% idle. (Quad 2ghz xeon) -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/

Re: [PERFORM] Scaling further up

bably want to bet the farm on something proven. lots and lots of spindles lots and lots of ram You may also want to look into a replication solution as a hot backup. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadca

[PERFORM] Fixed width rows faster?

o be able to hit row N in O(1), but that isn't what I'd call a real database. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] compiling 7.4.1 on Solaris 9

8, though, not 9. A thanks, i remember a thread about problems with flags passed to gcc on solaris. I was wondering if there had been any resolution and if the defaults for 7.4 are considered Ok. Yes. The compile flags on solaris were fixed on 7.4. Previously it wasn't using any optimiza

Re: [PERFORM] postgresql random io test with 2 SSD Kingston V+100 500GB in (software) Raid1

usp of stalling here. btw, yay pgiosim! :) -- Jeff Trout http://www.stuarthamm.net/ http://www.dellsmartexitin.com/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Benchmarking a large server

threads (rather than firing up a bunch of pgiosims in parallel) and see how things scale up. -- Jeff Trout http://www.stuarthamm.net/ http://www.dellsmartexitin.com/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: ht

Re: [PERFORM] Using pgiosim realistically

ndry? the -w param to pgiosim has it rewrite blocks out as it runs. (it is a percentage). -- Jeff Trout http://www.stuarthamm.net/ http://www.dellsmartexitin.com/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Using pgiosim realistically

pure read tests. It looks like I just need multiple threads so I can have multiple reads/writes in flight at the same time. Yep - you need multiple threads to get max throughput of your io. -- Jeff Trout http://www.stuarthamm.net/ http://www.dellsmartexitin.com/ -- Sent via pgsql-performance

Re: [PERFORM] Replaying 48 WAL files takes 80 minutes

On Oct 29, 2012, at 12:42 PM, Jeff Janes wrote: > On Mon, Oct 29, 2012 at 6:05 AM, Albe Laurenz wrote: >> I am configuring streaming replication with hot standby >> with PostgreSQL 9.1.3 on RHEL 6 (kernel 2.6.32-220.el6.x86_64). >> PostgreSQL was compiled from source.

[PERFORM] DATA directory on network attached storage

s the performance of gigE good enough to allow postgres to perform under load with an NFS mounted DATA dir? Are there other problems I haven't thought about? Any input would be greatly appreciated. Thanks! -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consul

[PERFORM] What to do with 6 disks?

xRAID5 for data c) 1xRAID10 for OS/xlong/data d) 1xRAID1 for OS, 1xRAID10 for data e) . I was initially leaning towards b, but after talking to Josh a bit, I suspect that with only 4 disks the raid5 might be a performance detriment vs 3 raid 1s or some sort of split raid10 setup. -- Jeff Fr

Re: [PERFORM] Opteron vs Xeon (Was: What to do with 6 disks?)

stems, though I have heard from a few Postgres folks that a dual Opteron is 2.5x as fast as a dual Xeon. I would think that AMD would be all over that press if they could show it, so what am I missing? Is it a bus speed thing? Better south bridge on the boards? -- Jeff Frost, Owner <[

[PERFORM] How to tell what your postgresql server is doing

e's a way to extract that sort of info from other metrics it keeps in the stats table? Maybe a script which polls the stats table and correlates the info with stats about the system in /proc? -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostc

Re: [PERFORM] Opteron vs Xeon (Was: What to do with 6 disks?)

se to 2.0x performance: http://www.anandtech.com/linux/showdoc.aspx?i=2163&p=2 It's an Opteron 150 (2.4ghz) vs. Xeon 3.6ghz from August. I wonder if the differences are more pronounced with the newer Opterons. -Jeff ---(end of broadcast)---

Re: [PERFORM] Whence the Opterons?

spx?i=2163&p=2 It's a little old, as it's listing an Opteron 150 vs 3.6 Xeon, but it does show that the opteron comes in almost twice as fast as the Xeon doing Postgres. -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Ph

Re: [PERFORM] Looking for tips

really prepared. That depends on what version you are using. Older versions did what Tom mentioned rather than sending PREPARE & EXECUTE. Not sure what version that changed in. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stua

Re: [PERFORM] COPY insert performance

ovement thereafter. Do you have a recommendation for a value? there's been a thread on -hackers recently about checkpoint issues.. in a nut shell there isn't much to do. But I'd say give bizgres a try if you're going to be continually loading huge amounts of data. -- Jeff T

Re: [SPAM?] Re: [PERFORM] PG8 Tuning

look into some more hardware.. see if you can borrow any or fabricate a "poor man"'s equivalent for testing. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 5

Re: [PERFORM] extremly low memory usage

have any real effect? This doesn't allocate anything - it is a hint to the planner about how much data it can assume is cached. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--

[PERFORM] OSX & Performance

#s, but no timing data. Instead you can do something even better - compile PG normally and attach to it with Shark (Comes with the CHUD tools) and check out its profile. Quite slick actually :) I'll keep people updated on my progress, but I just wanted to get these issues out in the

Re: [PERFORM] OSX & Performance

Thread model: posix gcc version 4.0.0 (Apple Computer, Inc. build 5026) The snapshot on ftp.psotgresql.org (dated 8/29) also runs with no optimization. No cflags are set. need to see anything from config.log? -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/

Re: [PERFORM] OSX & Performance

roblem). I could also get you access to this machine, but be warned gprof on tiger is pretty useless from what I've seen. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [PERFORM] Massive performance issues

http://www.powerpostgresql.com/PerfList/ -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 1: if posting/read

[PERFORM] Status of Opteron vs Xeon

What's the current status of how much faster the Opteron is compared to the Xeons? I know the Opterons used to be close to 2x faster, but is that still the case? I understand much work has been done to reduce the contect switching storms on the Xeon architecture, is this correct? --

Re: [PERFORM] Temporary Table

ft Lockspam to fight spam, and you? http://www.polesoft.com/refer.html ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsu

Re: [PERFORM] System queue

(loadavg) with low cpu usage means you are IO bound. Either change some queries around to generate less IO, or add more disks. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 2:

[PERFORM] Open request for benchmarking input

bit user-space; data warehouse type tests (data >> memory); and web prefs test (active data RAM) What specific benchmarks should be run, and what other things should be tested? Where should I go for assistance on tuning each database, evaluating the benchmark results, and re-tuning them?&qu

Re: [PERFORM] Joining 2 tables with 300 million rows

alue. Another thing that may be a factor is the network - when doing explain analyze it doesn't have to transfer the dataset to the client. -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)---

Re: [PERFORM] Defining performance.

on what kind of performance degradation you're experiencing. Am I missing something? Regards, Jeff Davis ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [PERFORM] Configuration settings for 32GB RAM server

ses 6 bytes. That means you could set it to 10 times the number you currently have, and it would still be insignificant. Regards, Jeff Davis ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

[PERFORM] opportunity to benchmark a quad core Xeon

benchmarks with what settings would be desirable to see how this system performs. I don't believe I've seen any postgres benchmarks done on a quad xeon yet. -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7

Re: [PERFORM] opportunity to benchmark a quad core Xeon

On Sat, 16 Dec 2006, Arjen van der Meijden wrote: On 16-12-2006 4:24 Jeff Frost wrote: We can add more RAM and drives for testing purposes. Can someone suggest what benchmarks with what settings would be desirable to see how this system performs. I don't believe I've seen an

Re: [PERFORM] High update activity, PostgreSQL vs BigDBMS

lways faster than the other two options. I didn't test any other filesystems in this go around. -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(

Re: [PERFORM] High update activity, PostgreSQL vs BigDBMS

h tables are used in hash joins, hash-based aggregation, and hash-based processing of IN subqueries." Regards, Jeff Davis ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [PERFORM] High update activity, PostgreSQL vs BigDBMS

On Tue, 9 Jan 2007, Jim C. Nasby wrote: On Thu, Dec 28, 2006 at 02:15:31PM -0800, Jeff Frost wrote: When benchmarking various options for a new PG server at one of my clients, I tried ext2 and ext3 (data=writeback) for the WAL and it appeared to be fastest to have ext2 for the WAL. The

Re: [PERFORM] High update activity, PostgreSQL vs BigDBMS

faster than ext3, but of course you could likely go with another filesystem yet and be even slightly faster as well. :-) I guess the real moral of the story is that you can probably use one big ext3 with the default config and it won't matter much more than 1-2% if you have a BBU. -- J

Re: [PERFORM] drive configuration for a new server

. In our case, the battery backed write cache seemed to remove the need for a separate WAL disk, but someone elses workload might still benefit from it. -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 65

Re: [PERFORM] How to debug performance problems

to provide queries, and also define "slower". Set log_min_duration_statement to some positive value (I often start with 1000) to try to catch the slow statements in the logs. Once you have found the slow statements, do an EXPLAIN and an EXPLAIN ANALYZE on those statemen

Re: [PERFORM] SELECT performance problem

ze output from 7.4.5 and 8.2.3 for the query in question? Also, is the hardware the same between 7.4.5 and 8.2.3? If not, what is the difference? -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-

[PERFORM] long checkpoint_timeout

ause extra disk I/O. Is there a good way to measure how much extra I/O (and WAL volume) is caused by the checkpoints? Also, it would be good to know how much total I/O is caused by a checkpoint so that I know if bgwriter is doing it's job. Regards, Jeff Davis ---

Re: [PERFORM] long checkpoint_timeout

nt, that would answer a lot of my questions. I did some brief searching and nothing turned up. Do you have a link to the discussion or the patch? Regards, Jeff Davis ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ign

Re: [PERFORM] Writting a "search engine" for a pgsql DB

indexes to return search results very quickly. As someone already mentioned, it also has ranking features. Regards, Jeff Davis ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [PERFORM] Two hard drives --- what to do with them?

e checkpoint have successfully made it to disk. If the write cache holds those data pages, and then loses them, there's no way for PostgreSQL to recover. So use a battery backed cache or turn off the write cache. Regards, Jeff Davis ---

Re: [PERFORM] Two hard drives --- what to do with them?

On Tue, 2007-02-27 at 01:11 +0100, Peter Kovacs wrote: > On 2/26/07, Jeff Davis <[EMAIL PROTECTED]> wrote: > > On Sun, 2007-02-25 at 23:11 +0100, Peter Kovacs wrote: > > > A related question: > > > Is it sufficient to disable write cache only on the disk where pg

Re: [PERFORM] Two hard drives --- what to do with them?

huge amounts of money on NVRAM (or something) to store your data. So identify the highest-risk scenarios and prevent those first. Also keep in mind what the cost of failure is: a few hundred bucks more on a better RAID controller is probably a good value if it prevents a day of chaos and un

Re: [PERFORM] strange performance regression between 7.4 and 8.1

one of the 10x slower queries would probably be handy. What do you mean by "created from scratch rather than copying over the old one"? How did you put the data in? Did you run analyze after loading it? Is autovacuum enabled and if so, what are the thresholds? -- Jeff Frost, Owne

Re: [PERFORM] strange performance regression between 7.4 and 8.1

On Thu, 1 Mar 2007, Alex Deucher wrote: On 3/1/07, Jeff Frost <[EMAIL PROTECTED]> wrote: On Thu, 1 Mar 2007, Joshua D. Drake wrote: > Alex Deucher wrote: >> Hello, >> >> I have noticed a strange performance regression and I'm at a loss as >> to wha

Re: [PERFORM] strange performance regression between 7.4 and 8.1

nie tests? Probably want to tune random_page_cost as well if it's also at the default. -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadca

Re: [PERFORM] strange performance regression between 7.4 and 8.1

On Thu, 1 Mar 2007, Alex Deucher wrote: On 3/1/07, Jeff Frost <[EMAIL PROTECTED]> wrote: On Thu, 1 Mar 2007, Alex Deucher wrote: >> Vacuum? Analayze? default_statistics_target? How many shared_buffers? >> effective_cache_size? work_mem? >> > > I'm runnin

Re: [PERFORM] strange performance regression between 7.4 and 8.1

e analyze running merrily along in the background. It's probably not as bad off as you think. At least this query isn't 10x. :-) Run these again for us after analyze is complete. -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC h

Re: [PERFORM] strange performance regression between 7.4 and 8.1

t and costs quite a bit less than a SAN. Is the SAN being shared between the database servers and other servers? Maybe it was just random timing that gave you the poor write performance on the old server which might be also yielding occassional poor performance on the new one. -- Jeff Fro

Re: [PERFORM] strange performance regression between 7.4 and 8.1

On Thu, 1 Mar 2007, Alex Deucher wrote: On 3/1/07, Jeff Frost <[EMAIL PROTECTED]> wrote: On Thu, 1 Mar 2007, Alex Deucher wrote: >> >> Postgresql might be choosing a bad plan because your >> effective_cache_size >> >> is >> >> way off (it'

Re: [PERFORM] Array indexes, GIN?

disk pages you need to fetch enough to make up for the extra cost of random I/O. Regards, Jeff Davis ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [PERFORM] strange performance regression between 7.4 and 8.1

ntly going from SQL_ASCII to UTF8. In 8.1 you can do this: SELECT datname, pg_size_pretty(pg_database_size(datname)) AS size FROM pg_database; In 7.4, you'll need to install the dbsize contrib module to get the same info. -- Jeff Frost, Owner <[EMAIL PROTECTED]> Fr

[PERFORM]

nt of time required. I am curious why the vacuum analyze makes it slower and if that gives any clues as too which parameter I should be tuning. BTW, I know the query could be re-structured more cleanly to remove the sub-selects, but that doesn't impact the performance. thanks, Jeff

[PERFORM] query slows down after vacuum analyze

nt of time required. I am curious why the vacuum analyze makes it slower and if that gives any clues as too which parameter I should be tuning. BTW, I know the query could be re-structured more cleanly to remove the sub-selects, but that doesn't seem to impact the performance. th

Re: [PERFORM]

On Mar 5, 2007, at 8:54 PM, Tom Lane wrote: Hm, the cost for the upper nestloop is way less than you would expect given that the HASH IN join is going to have to be repeated 100+ times. I think this must be due to a very low "join_in_selectivity" estimate but I'm not sure why you are getting

Re: [PERFORM]

ymptom_ids. Could this cause the problem and would there be anything I could do to address it? Thanks for all your help, I appreciate it. -Jeff ---(end of broadcast)--- TIP 4: Have you searched our list archives?

Re: [PERFORM]

e the query per Ismo's suggestion, or b) wait until more data comes into that table, potentially kicking the query planner into not using the Nested Loop anymore. Anyway, thanks again, I appreciate it... -Jeff On Mar 7, 2007, at 11:37 AM, Tom Lane wrote: Jeff Cole <[EMAIL PROTECTED]

Re: [PERFORM] SCSI vs SATA

pg_xlog+OS. Your workload may vary, but it's definitely worth testing. The system in question had 1GB BBU. -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---

Re: [PERFORM] High Load on Postgres 7.4.16 Server

ove: http://archives.postgresql.org/pgsql-performance/2007-03/msg00104.php -- Jeff Frost, Owner <[EMAIL PROTECTED]> Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 5:

<    1   2   3   4   5   6   7   8   9   >