Re: [PERFORM] Specifications for a new server

On Thu, May 08, 2014 at 10:11:38AM +0200, Johann Spies wrote: I understand your remark about the CPU in the light of my wrong assumption earlier, but I do not understand your remark about the RAM.  The fact that temporary files of up to 250Gb are created at times during complex queries, is to me

Re: [PERFORM] Specifications for a new server

On Tue, May 06, 2014 at 01:15:10PM +0200, Dorian Hoxha wrote: Since the commitlog/WAL is sequential-write, does it mattert that much to put it in ssd No, assuming a good storage system with nvram write buffer. Mike Stone -- Sent via pgsql-performance mailing list (pgsql-performance@postgr

Re: [PERFORM] Specifications for a new server

On Tue, May 06, 2014 at 11:13:42AM +0200, Johann Spies wrote: Analysis or the SAR-logs showed that there were too much iowait in the CPU's on the old system which has a lower spec CPU than the ones considered for the new system. iowait means the cpu is doing nothing but waiting for data from th

Re: [PERFORM] Optimal settings for RAID controller - optimized for writes

On Mon, Feb 17, 2014 at 04:29:10PM +0100, DFE wrote: 2xSSD (MLC) Raid1 for Operating System (CentOS 6.4) 4xSSD (SLC) Raid10 for WAL archive and a dedicated "fast tablespace", where we have most UPDATE actions (+ Hot spare). 10xHDD 15kRPM Raid5 for "default tablespace" (optimized for space, instea

Re: [PERFORM] Testing Sandforce SSD

On Wed, Jul 28, 2010 at 03:45:23PM +0200, Yeb Havinga wrote: Due to the LBA remapping of the SSD, I'm not sure of putting files that are sequentially written in a different partition (together with e.g. tables) would make a difference: in the end the SSD will have a set new blocks in it's buffe

Re: [PERFORM] Testing Sandforce SSD

On Mon, Jul 26, 2010 at 03:23:20PM -0600, Greg Spiegelberg wrote: I know I'm talking development now but is there a case for a pg_xlog block device to remove the file system overhead and guaranteeing your data is written sequentially every time? If you dedicate a partition to xlog, you already

Re: [PERFORM] Testing Sandforce SSD

On Mon, Jul 26, 2010 at 01:47:14PM -0600, Scott Marlowe wrote: Note that SSDs aren't usually real fast at large sequential writes though, so it might be worth putting pg_xlog on a spinning pair in a mirror and seeing how much, if any, the SSD drive speeds up when not having to do pg_xlog. xlog

Re: [PERFORM] 10K vs 15k rpm for analytics

Do keep the postgres xlog on a seperate ext2 partition for best performance. Other than that, xfs is definitely a good performer. Mike Stone -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgs

Re: [PERFORM] Benchmark: Dell/Perc 6, 8 disk RAID 10

On Sun, Mar 16, 2008 at 12:04:44PM -0700, Craig James wrote: Just out of curiosity: Last time I did research, the word seemed to be that xfs was better than ext2 or ext3. Is that not true? Why use ext2/3 at all if xfs is faster for Postgres? For the WAL, the filesystem is largely irrelevant.

Re: [PERFORM] Benchmark: Dell/Perc 6, 8 disk RAID 10

On Thu, Mar 13, 2008 at 05:27:09PM -0400, Greg Smith wrote: I haven't found fdatasync to be significantly better in my tests on Linux but I never went out of my way to try and quantify it. My understanding is that some of the write barrier implementation details on ext3 filesystems make any sy

Re: [PERFORM] Anyone using a SAN?

On Wed, Feb 20, 2008 at 02:52:42PM +0100, C. Bergström wrote: Can be, but may I point to a recent posting on Beowulf ml [1] and the article it references [2] Showing that the per node price of SDR IB has come down far enough to in some cases compete with GigE. ymmv, but I'm in the planning phase

Re: [PERFORM] Anyone using a SAN?

On Mon, Feb 18, 2008 at 03:44:40PM -0600, Peter Koczan wrote: One big reason we're really looking into a SAN option is that we have a lot of unused disk space. The cost of the SAN interfaces probably exceeds the cost of the wasted space, and the performance will probably be lower for a lot of

Re: [PERFORM] Best way to index IP data?

On Mon, Jan 14, 2008 at 03:05:27PM +0100, Florian Weimer wrote: Hmm. It's an argument for a separate CIDR type, not against a host type. I don't think anyone argued against the CIDR type. :-) Mike Stone ---(end of broadcast)--- TIP 6: explain a

Re: [PERFORM] Best way to index IP data?

On Mon, Jan 14, 2008 at 09:27:52AM +0100, Florian Weimer wrote: * Steve Atkins: I don't think there's ambiguity about what an dotted-quad without a netmask means, and hasn't been for a long time. Am I missing something? Classful addressing is still part of many user interfaces, for instance Ci

Re: [PERFORM] Best way to index IP data?

Tom wrote: There seem to be a number of people in this thread laboring under the illusion that we store a netmask as a mask. It's a bit count (think /32 or /128) and occupies a whole one byte on disk. Killer overhead, for sure. There's no need to be quite so snarky. The netmask isn't the on

Re: [PERFORM] Best way to index IP data?

On Fri, Jan 11, 2008 at 04:57:46PM -0800, Joshua D. Drake wrote: Question is.. are you going to have a few billion IPs in your database? Doubtful. Really depends on what you're using the database for, doesn't it? Mike Stone ---(end of broadcast)

Re: [PERFORM] Best way to index IP data?

On Fri, Jan 11, 2008 at 04:43:18PM -0800, Joshua D. Drake wrote: Sigh. No. But there is an RFC that declare how IPs are denoted and used. Sigh, I'm honestly curious about what RFC says that endpoint IPs must have netmasks associated with them. Mike Stone ---(end of b

Re: [PERFORM] Best way to index IP data?

On Fri, Jan 11, 2008 at 07:19:10PM -0500, Tom Lane wrote: It was correct, but not as of 8.3. Considering you could save a whole one byte by not storing the netmask Hmm. One for the netmask, plus the other two mystery bytes. :-) A byte here and a byte there is fine. 20% of a few billion IPs do

Re: [PERFORM] Best way to index IP data?

On Fri, Jan 11, 2008 at 03:52:11PM -0800, Joshua D. Drake wrote: Steve I think you are speaking of practicality and implementation versus RFC compliance. I believe per the RFC Andrew is correct. There's an RFC for storing IPs in a database? Mike Stone ---(end of broadc

Re: [PERFORM] Best way to index IP data?

On Fri, Jan 11, 2008 at 06:00:55PM -0500, Andrew Sullivan wrote: another way, without context, a dotted-quad is insufficient on its own. What you're really arguing is that the context ought to be storable somewhere else (maybe in a human's brain) Or, say, in a database schema, where you say "t

Re: [PERFORM] Best way to index IP data?

On Fri, Jan 11, 2008 at 06:37:10PM -0300, Alvaro Herrera wrote: So what this means is that our type oughta be optimized. How about having a separate bit to indicate whether there is a netmask or not, and chop the storage earlier. (I dunno if this already done) Why not just have a type that in

Re: [PERFORM] Best way to index IP data?

On Fri, Jan 11, 2008 at 04:32:05PM -0500, Michael Stone wrote: On Fri, Jan 11, 2008 at 03:19:35PM -0500, D'Arcy J.M. Cain wrote: Besides, there are many cases where you want to track both ipv4 and ipv6 for the same purpose and requiring two different fields would be less than ideal.

Re: [PERFORM] Best way to index IP data?

On Fri, Jan 11, 2008 at 03:19:35PM -0500, D'Arcy J.M. Cain wrote: Besides, there are many cases where you want to track both ipv4 and ipv6 for the same purpose and requiring two different fields would be less than ideal. And, there are many cases where you don't. I've got two kinds of db's tha

Re: [PERFORM] Best way to index IP data?

On Fri, Jan 11, 2008 at 03:07:38PM -0500, Tom Lane wrote: Michael Stone <[EMAIL PROTECTED]> writes: Well, a native IPv6 type would also be nice; inet is ridiculously bloated for both IPv4 *and* IPv6. Nonsense. 3 bytes overhead on a 16-byte address is not "ridiculously bloated&q

Re: [PERFORM] Best way to index IP data?

On Fri, Jan 11, 2008 at 10:19:51AM -0500, Tom Lane wrote: Given that the world is going to IPv6 in a few years whether you like it or not, that seems pretty darn short-sighted to me. Well, a native IPv6 type would also be nice; inet is ridiculously bloated for both IPv4 *and* IPv6. Mike Sto

Re: [PERFORM] viewing source code

On Thu, Dec 20, 2007 at 02:02:57PM -0600, Roberts, Jon wrote: I'm tired of arguing. You win. I still say this I a needed feature if you want adoption for enterprise level databases in larger companies. The security out of the box is not enough What a classic "I want this, and if it isn't im

Re: [PERFORM] database tuning

On Wed, Dec 12, 2007 at 12:27:39PM +1200, kelvan wrote: I have also learnt and also Richard pointed out just not in so many words the difference in support from a open source community compared to a non open source company is that the people who give support in open source are opinionated rathe

Re: [PERFORM] TB-sized databases

On Thu, Dec 06, 2007 at 11:13:18AM -0500, Tom Lane wrote: Indeed, and if you've got examples where it's that far off, you should report them. Yeah, the trick is to get it to a digestable test case. The basic scenario (there are more tables & columns in the actual case) is a set of tables part

Re: [PERFORM] TB-sized databases

On Thu, Dec 06, 2007 at 09:38:16AM +, Simon Riggs wrote: The issue is that if somebody issues a "large query" then it will be a problem whichever plan the query takes. Forcing index scans can make a plan more expensive than a seq scan in many cases. OTOH, the planner can really screw up que

Re: [PERFORM] SAN vs Internal Disks

On Tue, Sep 11, 2007 at 06:07:44PM -0500, Decibel! wrote: On Tue, Sep 11, 2007 at 05:09:00PM -0400, Michael Stone wrote: You can get DAS arrays with multiple controllers, PSUs, etc. DAS != single disk. It's still in the same chassis, though, I think you're confusing DAS an

Re: [PERFORM] SAN vs Internal Disks

On Tue, Sep 11, 2007 at 03:55:51PM -0500, Decibel! wrote: Also, to reply to someone else's email... there is one big reason to use a SAN over direct storage: you can do HA that results in 0 data loss. Good SANs are engineered to be highly redundant, with multiple controllers, PSUs, etc, so that t

Re: [PERFORM] SAN vs Internal Disks

On Fri, Sep 07, 2007 at 12:33:41PM +0200, Tobias Brox wrote: Advantages: 1. Higher I/O (at least the salesman claims so) Benchmark it. It is extremely unlikely that you'll get I/O *as good as* DAS at a similar price point. 2. Easier to upgrade the disk capacity Is this an issue? You may

Re: [PERFORM] postgres memory management issues?

On Thu, Sep 06, 2007 at 09:06:53AM -0700, Richard Yen wrote: My understanding is that if any one postgres process's memory usage, plus the shared memory, exceeds the kernel limit of 4GB, On a 32 bit system the per-process memory limit is a lot lower than 4G. If you want to use 16G effectively

Re: [PERFORM] SAN vs Internal Disks

On Fri, Sep 07, 2007 at 12:26:23AM -0400, Greg Smith wrote: consider is this: your SAN starts having funky problems, and your database is down because of it. You call the vendor. They find out you're running CentOS instead of RHEL and say that's the cause of your problem (even though it prob

Re: [PERFORM] Bad planner decision - bitmap scan instead of index

On Fri, Aug 17, 2007 at 10:43:18AM +0200, Frank Schoep wrote: On Aug 17, 2007, at 9:28 AM, hubert depesz lubaczewski wrote: (cost=0.00..37612.76 rows=14221 width=48) (actual time=0.125..13.686 rows=2000 loops=1) [snip] I'm not an expert at how the planner decides which query plan to use, N

Re: [PERFORM] Update table performance

On Thu, Aug 09, 2007 at 06:04:09PM +0530, Merlin Moncure wrote: keep an eye for the HOT feature which will hopefully make 8.3 that will highly reduce the penalty for (small) updates in many cases. Is there an overview somewhere about how this feature works and what it is expected to do? There

Re: [PERFORM] insert vs select into performance

On Wed, Jul 18, 2007 at 09:13:14PM +0200, Thomas Finneid wrote: Michael Stone wrote: I don't understand how the insert you described is table to table? SELECT INTO is table to table, so is INSERT INTO SELECT FROM. I could have sworn that at least one of the examples you gave didn&#x

Re: [PERFORM] insert vs select into performance

On Tue, Jul 17, 2007 at 11:01:15PM +0200, Thomas Finneid wrote: Arjen van der Meijden wrote: Have you also tried the COPY-statement? Afaik select into is similar to what happens in there. No, because it only works on file to db or vice versa not table to table. I don't understand how the ins

Re: [PERFORM] insert vs select into performance

On Tue, Jul 17, 2007 at 10:58:01PM +0200, Thomas Finneid wrote: I am not sure I understand you correctly here, are you saying that SELECT INTO in 8.1 disables WAL logging and uses just a single fsync at the end? in that case it means that I could disable WAL as well and achieve the same perform

Re: [PERFORM] insert vs select into performance

On Tue, Jul 17, 2007 at 10:50:22PM +0200, Thomas Finneid wrote: I havent done this test in a stored function yet, nor have I tried it with a C client so far, so there is the chance that it is java/jdbc that makes the insert so slow. I'll get to that test soon if there is any chance my theory ma

Re: [PERFORM] TRUNCATE TABLE

On Fri, Jul 13, 2007 at 09:47:06AM +0200, Adriaan van Os wrote: That's a remarkable advice, because XFS is known to be slow at creating and deleting files, see and . xfs' slowness is proportional to the *number

Re: [PERFORM] Performance query about large tables, lots of concurrent access

On Thu, Jun 21, 2007 at 12:29:49PM -0400, Karl Wright wrote: I checked the disk picture - this is a RAID disk array with 6 drives, with a bit more than 1Tbyte total storage. 15,000 RPM. It would be hard to get more/faster disk than that. Well, it's not hard to more disk than that, but you'd

Re: [PERFORM] Performance query about large tables, lots of concurrent access

On Wed, Jun 20, 2007 at 11:14:45AM -0700, Joshua D. Drake wrote: Michael Stone wrote: Is there a sensible way to partition the large table into smaller tables? It entirely depends on your data set. Yes, that's why it was a question rather than a suggestion. :) Mike

Re: [PERFORM] Performance query about large tables, lots of concurrent access

Is there a sensible way to partition the large table into smaller tables? Mike Stone ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your

Re: [PERFORM] setting up raid10 with more than 4 drives

On Wed, May 30, 2007 at 10:36:48AM -0400, Luke Lonergan wrote: I don't see how that's better at all; in fact, it reduces to exactly the same problem: given two pieces of data which disagree, which is right? The one that matches the checksum. And you know the checksum is good, how? Mike St

Re: [PERFORM] setting up raid10 with more than 4 drives

On Wed, May 30, 2007 at 07:06:54AM -0700, Luke Lonergan wrote: On 5/30/07 12:29 AM, "Peter Childs" <[EMAIL PROTECTED]> wrote: Good point, also if you had Raid 1 with 3 drives with some bit errors at least you can take a vote on whats right. Where as if you only have 2 and they disagree how do yo

Re: [PERFORM] ECC RAM really needed?

On Fri, May 25, 2007 at 06:45:15PM -0700, Craig James wrote: We're thinking of building some new servers. We bought some a while back that have ECC (error correcting) RAM, which is absurdly expensive compared to the same amount of non-ECC RAM. Does anyone have any real-life data about the err

Re: [PERFORM] [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal

On Wed, May 16, 2007 at 03:34:42PM -0400, Chris Browne wrote: [EMAIL PROTECTED] (Michael Stone) writes: Unless, of course, you don't particularly care about the order of the items in your table; you might end up wasting vastly more time rewriting tables due to unnecessary clustering tha

Re: [PERFORM] [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal

On Wed, May 16, 2007 at 12:09:26PM -0400, Alvaro Herrera wrote: Maybe, but we should also mention that CLUSTER is a likely faster workaround. Unless, of course, you don't particularly care about the order of the items in your table; you might end up wasting vastly more time rewriting tables d

Re: [PERFORM] [doc patch] a slight VACUUM / VACUUM FULL doc improvement proposal

On Tue, May 15, 2007 at 06:43:50PM +0200, Guillaume Cottenceau wrote: patch - basically, I think the documentation under estimates (or sometimes misses) the benefit of VACUUM FULL for scans, and the needs of VACUUM FULL if the routine VACUUM hasn't been done properly since the database was put in

Re: [PERFORM] pg_stat_* collection

On Fri, May 04, 2007 at 12:53:55AM -0400, Greg Smith wrote: It's also completely inappropriate for any environment I work in, because there really is no thought of security whatsoever in the whole thing. That makes it sound more like snmp, not less. :-) Mike Stone ---

Re: [PERFORM] Feature Request --- was: PostgreSQL Performance Tuning

On Fri, May 04, 2007 at 12:33:29AM -0400, Greg Smith wrote: -bash-3.00$ psql postgres=# \timing Timing is on. postgres=# select count(*) from generate_series(1,10,1); count 10 (1 row) Time: 106.535 ms There you go, a completely cross-platform answer. You should run the stat

Re: [PERFORM] Feature Request --- was: PostgreSQL Performance Tuning

On Fri, Apr 27, 2007 at 07:36:52AM -0700, Mark Lewis wrote: Maybe he's looking for a switch for initdb that would make it interactive and quiz you about your expected usage-- sort of a magic auto-configurator wizard doohicky? I could see that sort of thing being nice for the casual user or newbi

Re: [PERFORM] Feature Request --- was: PostgreSQL Performance Tuning

On Fri, Apr 27, 2007 at 09:27:49AM -0400, Carlos Moreno wrote: Notice that the second part of my suggestion covers this --- have additional switches to initdb so that the user can tell it about estimates on how the DB will be used: estimated size of the DB, estimated percentage of activity tha

Re: [PERFORM] Usage up to 50% CPU

On Fri, Apr 27, 2007 at 07:23:41PM +0930, Shane Ambler wrote: I would think that as you are sitting and watching the cpu usage, your query would seem to taking a while to run, leading me to wonder if you are getting a full table scan that is causing pg to wait for disk response? If so, you pro

Re: [PERFORM] SCSI vs SATA

On Fri, Apr 06, 2007 at 03:37:08PM -0400, Ron wrote: studies. I respect that. Unfortunately the RW is too fast moving and too messy to wait for a laboratory style study to be completed before we are called on to make professional decisions on most issues we face within our work IME I have to

Re: [PERFORM] SCSI vs SATA

On Fri, Apr 06, 2007 at 12:41:25PM -0400, Ron wrote: 3.based on personal observation, case study reports, or random investigations rather than systematic scientific evaluation: anecdotal evidence. Here you even quote the appropriate definition before ignoring it. In short, professional advic

Re: [PERFORM] SCSI vs SATA

On Fri, Apr 06, 2007 at 08:49:08AM -0400, Ron wrote: Not quite. Each of our professional experiences is +also+ statistical evidence. Even if it is a personally skewed sample. I'm not sure that word means what you think it means. I think the one you're looking for is "anecdotal". My experie

Re: [PERFORM] SCSI vs SATA

On Fri, Apr 06, 2007 at 02:00:15AM -0400, Tom Lane wrote: It seems hard to believe that the vendors themselves wouldn't burn in the drives for half a day, if that's all it takes to eliminate a large fraction of infant mortality. The savings in return processing and customer goodwill would surely

Re: [PERFORM] SCSI vs SATA

On Thu, Apr 05, 2007 at 11:19:04PM -0400, Ron wrote: Both statements are the literal truth. Repeating something over and over again doesn't make it truth. The OP asked for statistical evidence (presumably real-world field evidence) to support that assertion. Thus far, all the publicly availab

Re: [PERFORM] scalablility problem

On Fri, Mar 30, 2007 at 10:00:30PM -0600, Guido Neitzer wrote: On 30.03.2007, at 19:18, Christopher Browne wrote: 2. There are known issues with the combination of Xeon processors and PAE memory addressing; that sort of hardware tends to be *way* less speedy than the specs would suggest. That

Re: [PERFORM] Parallel Vacuum

On Fri, Mar 23, 2007 at 04:37:32PM +0100, Dimitri wrote: Speed-up x4 is obtained just because single vacuum process reaching max 80MB/sec in throughput I'd look at trying to improve that, it seems very low. Mike Stone ---(end of broadcast)--- TI

Re: [PERFORM] Performance of count(*)

On Fri, Mar 23, 2007 at 01:01:02PM +0100, Tino Wildenhain wrote: This discussion is a bit theoretical until we see the actual problem and the proposed solution here. It's good to see you back off a bit from your previous stance of assuming that someone doesn't know what they're doing and that

Re: [PERFORM] Performance of count(*)

On Thu, Mar 22, 2007 at 02:24:39PM -0400, Merlin Moncure wrote: Tino was saying that rather that build a complete indexing storage management solution that lives outside the database, it is better to do intelligent session management so that you get the simplicity if a two tier client server syst

Re: [PERFORM] Parallel Vacuum

On Thu, Mar 22, 2007 at 07:24:38PM +0100, Dimitri wrote: you're right until you're using a single disk :) Now, imagine you have more disks I do have more disks. I maximize the I/O performance by dedicating different sets of disks to different tables. YMMV. I do suggest watching your I/O rates

Re: [PERFORM] Performance of count(*)

On Thu, Mar 22, 2007 at 06:27:32PM +0100, Tino Wildenhain wrote: Craig A. James schrieb: You guys can correct me if I'm wrong, but the key feature that's missing from Postgres's flexible indexing is the ability to maintain state across queries. Something like this: select a, b, my_index_sta

Re: [PERFORM] Parallel Vacuum

On Thu, Mar 22, 2007 at 04:55:02PM +0100, Dimitri wrote: In my case I have several CPU on the server and quite powerful storage box which is not really busy with a single vacuum. So, my idea is quite simple - speed-up vacuum with parallel execution (just an algorithm): Vacuum is I/O intensive,

Re: [PERFORM] Performance of count(*)

On Thu, Mar 22, 2007 at 09:39:18AM -0400, Merlin Moncure wrote: You can get the approximate count by selecting reltuples from pg_class. It is valid as of last analyze. Of course, that only works if you're not using any WHERE clause. Here's a (somewhat ugly) example of getting an approximate c

Re: [PERFORM] Performance of count(*)

On Thu, Mar 22, 2007 at 01:30:35PM +0200, [EMAIL PROTECTED] wrote: approximated count? why? who would need it? where you can use it? Do a google query. Look at the top of the page, where it says "results N to M of about O". For user interfaces (which is where a lot of this count(*) stuff

Re: [PERFORM] Performance Tuning and Disk Cache

On Sun, Mar 18, 2007 at 06:45:34AM -0600, Barry Moore wrote: Does anyone know how I can repeatedly run the same query in the "worst case scenario" of no postgres data in the disk cache (e.g., clear the page cache or force it to be ignored)? Depends on your OS. On linux you can run: echo 1 >

Re: [PERFORM] New to PostgreSQL, performance considerations

On Sat, Dec 16, 2006 at 10:53:21AM -0500, Ron wrote: The most important "gain" IMO is Knowledge, and I'd say there is still more to learn and/or verify IMHO. YMMV. Well, I think there are other areas where I can spend my time where potential gains are more likely. YMMV (although, I note, you d

Re: [PERFORM] New to PostgreSQL, performance considerations

On Fri, Dec 15, 2006 at 12:24:46PM -0500, Ron wrote: ATM, the most we can say is that in a number of systems with modest physical IO subsystems So I reran it on a 3.2GHz xeon with 6G RAM off a ramdisk; I/O ain't the bottleneck on that one. Results didn't show didn't show any signficant gain

Re: [PERFORM] New to PostgreSQL, performance considerations

On Wed, Dec 13, 2006 at 01:03:04PM -0500, Ron wrote: What I find interesting is that so far Guido's C2D Mac laptop has gotten the highest values by far in this set of experiments, and no one else is even close. The slowest results, Michael's, are on the system with what appears to be the slowes

Re: [PERFORM] New to PostgreSQL, performance considerations

On Tue, Dec 12, 2006 at 07:48:06AM -0500, Michael Stone wrote: I'd be curious to see -O2 with and without the arch-specific flags, since that's mostly what the discussion is about. That came across more harshly than I intended; I apologize for that. It's certainly a usefu

Re: [PERFORM] New to PostgreSQL, performance considerations

On Tue, Dec 12, 2006 at 01:42:06PM +0100, Cosimo Streppone wrote: "-O0" ~ 957 tps "-O1 -mcpu=pentium4 -mtune=pentium4" ~ 1186 tps "-O2 -mcpu=pentium4 -mtune=pentium4" ~ 1229 tps "-O3 -mcpu=pentium4 -mtune=pentium4" ~ 1257 tps "-O6 -mcpu=pentium4 -mtune=pentium4" ~ 1254 tps I'm curious now to get

Re: [PERFORM] New to PostgreSQL, performance considerations

On Tue, Dec 12, 2006 at 12:29:29PM +0100, Alexander Staubo wrote: I suspect the hardware's real maximum performance of the system is ~150 tps, but that the LSI's write cache is buffering the writes. I would love to validate this hypothesis, but I'm not sure how. With fsync off? The write cac

Re: [PERFORM] New to PostgreSQL, performance considerations

On Tue, Dec 12, 2006 at 07:10:34AM -0200, Daniel van Ham Colchete wrote: are you using "-mtune/-mcpu" or "-march" with GCC? I used exactly the options you said you used. Witch GCC version? Are you working with a 32bits OS or 64bits? 3.3.5; 32 Mike Stone ---(end of

Re: [PERFORM] New to PostgreSQL, performance considerations

On Tue, Dec 12, 2006 at 01:35:04AM -0500, Greg Smith wrote: These changes could easily explain the magnitude of difference in results you're seeing, expecially when combined with a 20% greater raw CPU clock. I'm not interested in comparing the numbers between the systems (which is obviously po

Re: [PERFORM] New to PostgreSQL, performance considerations

On Mon, Dec 11, 2006 at 08:22:42PM -0200, Daniel van Ham Colchete wrote: TEST 01: CFLAGS="-O2 -march=i686" fsync=false tps = 734.948620 (including connections establishing) tps = 736.866642 (excluding connections establishing) [snip] TEST 03: CFLAGS="-O2 -march=pentium4" fsync=false tps = 846

Re: [PERFORM] New to PostgreSQL, performance considerations

On Mon, Dec 11, 2006 at 02:51:09PM -0500, Ron wrote: Let's support getting definitive evidence. Since nobody opposed the concept of contrary evidence, I don't suppose you're fighting an uphill battle on that particular point. It's fine to get preachy about supporting intellectual curiosity,

Re: [PERFORM] New to PostgreSQL, performance considerations

On Mon, Dec 11, 2006 at 10:30:55AM -0800, Luke Lonergan wrote: Here's one - I wrote a general purpose Computational Fluid Dynamics analysis method used by hundreds of people to perform aircraft and propulsion systems analysis. That's kinda the opposite of what I meant by general code. I was t

Re: [PERFORM] New to PostgreSQL, performance considerations

On Mon, Dec 11, 2006 at 01:20:50PM -0500, Ron wrote: (The validity of the claim has nothing to do with the skills or experience of the claimant or anyone else in the discussion. Only on the evidence.) Please go back and reread the original post. I don't think the response was unwarranted.

Re: [PERFORM] New to PostgreSQL, performance considerations

On Mon, Dec 11, 2006 at 12:15:51PM -0500, Ron wrote: I'd say the fairest attitude is to do everything we can to support having the proper experiments done w/o presuming the results. Who's presuming results?[1] It is fair to say that making extraordinary claims without any evidence should be di

Re: [PERFORM] New to PostgreSQL, performance considerations

On Mon, Dec 11, 2006 at 09:05:56AM -0200, Daniel van Ham Colchete wrote: unfortunally I don't have any benchmarks right now. That's fairly normal for gentoo users pushing their compile options. Mike Stone ---(end of broadcast)--- TIP 4: Have you

Re: [PERFORM] File Systems Compared

On Wed, Dec 06, 2006 at 06:59:12PM +0100, Arnaud Lesauvage wrote: Markus Schiltknecht a écrit : What's common practice? What's it on the pgsql mailing lists? The netiquette usually advise mailers to wrap after 72 characters on mailing lists. This does not apply for format=flowed I guess (that

Re: [PERFORM] Bad iostat numbers

On Tue, Dec 05, 2006 at 07:57:43AM -0500, Alex Turner wrote: The problem I see with software raid is the issue of a battery backed unit: If the computer loses power, then the 'cache' which is held in system memory, goes away, and fubars your RAID. Since the Adaptec doesn't have a BBU, it's a la

Re: [PERFORM] Bad iostat numbers

On Tue, Dec 05, 2006 at 01:21:38AM -0500, Alex Turner wrote: My other and most important point is that I can't find any solid recommendations for a SCSI card that can perform optimally in Linux or *BSD. Off by a factor of 3x is pretty sad IMHO. (and yes, we know the Adaptec cards suck worse, tha

Re: [PERFORM] Bad iostat numbers

On Mon, Dec 04, 2006 at 12:52:46PM -0500, Alex Turner wrote: http://en.wikipedia.org/wiki/RAID_controller What is the wikipedia quote supposed to prove? Pray tell, if you consider RAID==HBA, what would you call a SCSI (e.g.) controller that has no RAID functionality? If you'd call it an HBA,

Re: [PERFORM] Bad iostat numbers

On Mon, Dec 04, 2006 at 12:37:29PM -0500, Alex Turner wrote: This discussion I think is important, as I think it would be useful for this list to have a list of RAID cards that _do_ work well under Linux/BSD for people as recommended hardware for Postgresql. So far, all I can recommend is what

Re: [PERFORM] Postgres server crash

On Sun, Nov 26, 2006 at 05:41:02PM -0600, Jim C. Nasby wrote: What's interesting is that apparently FreeBSD also has overcommit (and IIRC no way to disable it), yet I never hear people going off on OOM kills in FreeBSD. Could just be that nobody is using FreeBSD. Seriously, though, there are

Re: [PERFORM] Postgres server crash

On Sun, Nov 19, 2006 at 02:12:01PM -0800, Craig A. James wrote: And speaking of SGI, this very issue was among the things that sank the company. As the low-end graphics cards ate into their visualization market, they tried to become an Oracle Server platform. Their servers were *fast*. But t

Re: [PERFORM] Postgres server crash

On Sun, Nov 19, 2006 at 12:42:45PM -0800, Richard Broersma Jr wrote: I don't mean to hijack the thread, but I am interested in learning the science behind configuring memory usage. There isn't one. You need experience, and an awareness of your particular requirements. If it were easy, it w

Re: [PERFORM] Postgres server crash

On Sat, Nov 18, 2006 at 05:28:46PM -0800, Richard Troy wrote: On linux you can use the sysctl utility to muck with vm.overcommit_memory; You can disable the "feature." Be aware that there's are "reasons" the "feature" exists before you "cast" "aspersions" and "quote marks" all over the place,

Re: [PERFORM] Unsubscribe

On Wed, Oct 04, 2006 at 08:30:03AM -0700, Joshua D. Drake wrote: They don't follow what is largely considered standard amongst lists which is to have list information at the bottom of each e-mail. In my experience such a footer doesn't do much to prevent people sending unsubscribe messages to

Re: [PERFORM] Large tables (was: RAID 0 not as fast as expected)

On Mon, Sep 18, 2006 at 07:14:56PM -0400, Alex Turner wrote: If you have a table with 100million records, each of which is 200bytes long, that gives you roughtly 20 gig of data (assuming it was all written neatly and hasn't been updated much). If you're in that range it doesn't even count as

Re: [PERFORM] Vacuums on large busy databases

On Thu, Sep 14, 2006 at 05:52:02PM -0700, Jeff Davis wrote: Any long-running system will have very little "free" memory. Free memory is wasted memory, so the OS finds some use for it. The important part of the output of "free" in this context isn't how much is free, it's how much is cache vs h

Re: [PERFORM] Vacuums on large busy databases

On Thu, Sep 14, 2006 at 08:04:39PM -0400, Francisco Reyes wrote: Wasn't trying to get an accurate value, just a ballpark figure. Won't even be a ballpark. When you say "free" are you refering to the free value from top? or some program called free? Depends on your OS. Mike Stone -

Re: [PERFORM] Vacuums on large busy databases

On Thu, Sep 14, 2006 at 04:30:46PM -0400, Francisco Reyes wrote: Right now adding up from ps the memory I have about 2GB. That's not how you find out how much memory you have. Try "free" or somesuch. Mike Stone ---(end of broadcast)--- TIP 5:

Re: [PERFORM] Which benchmark to use for testing FS?

On Wed, Aug 23, 2006 at 03:23:03PM -0700, Jeff Davis wrote: Also, do ext2 or UFS without soft updates run the risk of losing or corrupting my data? I suggest you check the list archives; there's a lot of stuff about filesystems and disk configuration in there. Mike Stone ---

Re: [PERFORM] Storage Options

On Mon, Aug 21, 2006 at 02:50:51PM -0700, Jeff Davis wrote: the NetApp over NFS, so I am not sure what performance to expect. Any suggestions about using network storage like this for the database? Don't. Unless you're using a very small (toy-scale) database, the netapp storage is way too expe

  1   2   3   >