Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On Tue, Aug 10, 2010 at 3:52 PM, Scott Marlowe wrote: > My point being, no matter how terrible an idea a certain storage media > is, there's always a use case for it.  Even if it's very narrow. The trouble is, if extra subscribers induce load on the "master," which they presumably will, then that

Re: [PERFORM] Oddly slow queries

Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Thomas Spreng) wrote: > On 16.04.2008, at 17:42, Chris Browne wrote: >> [EMAIL PROTECTED] (Thomas Spreng) writes: >>> On 16.04.2008, at 01:24, PFC wrote: > The queries in question (select's) occasionally take up to 5 mins >

Re: [PERFORM] scalablility problem

Quoth [EMAIL PROTECTED] (Xiaoning Ding): > When I run multiple TPC-H queries (DBT3) on postgresql, I found the system > is not scalable. My machine has 8GB memory, and 4 Xeon Dual Core processor > ( 8 cores in total). OS kernel is linux 2.6.9. Postgresql is 7.3.18. I > I think it might be caused

Re: [PERFORM] New to PostgreSQL, performance considerations

[EMAIL PROTECTED] (Alexander Staubo) wrote: > On Dec 12, 2006, at 13:32 , Michael Stone wrote: > >> 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

Re: [PERFORM] New to PostgreSQL, performance considerations

After a long battle with technology, [EMAIL PROTECTED] (Michael Stone), an earthling, wrote: > [1] I will say that I have never seen a realistic benchmark of > general code where the compiler flags made a statistically > significant difference in the runtime. When we were initially trying out Pos

Re: [PERFORM] New to PostgreSQL, performance considerations

Oops! [EMAIL PROTECTED] ("Daniel van Ham Colchete") was seen spray-painting on a wall: > But, trust me on this one. It's worth it. No, the point of performance analysis is that you *can't* trust the people that say "trust me on this one." If you haven't got a benchmark where you can demonstrate

Re: [PERFORM] Optimization of this SQL sentence

The world rejoiced as [EMAIL PROTECTED] (Shane Ambler) wrote: > Chris Browne wrote: >> In the case of a zip code? Sure. US zip codes are integer values >> either 5 or 9 characters long. > > So your app will only work in the US? > And only for US companies that only have US clients? > > > Sorry ha

Re: [PERFORM] Hints proposal

Quoth [EMAIL PROTECTED] (Richard Broersma Jr): >> By the way, wouldn't it be possible if the planner learned from a query >> execution, so it would know if a choice for a specific plan or estimate >> was actually correct or not for future reference? Or is that in the line >> of DB2's complexity

Re: [PERFORM] Postgre SQL 7.1 cygwin performance issue.

On 8/28/06, Tom Lane <[EMAIL PROTECTED]> wrote: "Christopher Browne" <[EMAIL PROTECTED]> writes: > On 8/28/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote: >> There's no solution short of upgrading. > That's a little too negative. There is at lea

Re: [PERFORM] Postgre SQL 7.1 cygwin performance issue.

On 8/28/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > Please advise us on how to resolve this ?. There's no solution short of upgrading. That's a little too negative. There is at least one alternative, possibly two... 1. Migrate the database to a Unix platform that does not suffer from th

Re: [PERFORM] Postgre SQL 7.1 cygwin performance issue.

On 8/28/06, Ravindran G - TLS, Chennai. <[EMAIL PROTECTED]> wrote: Thanks Alvaro. We are using PostgreSQL 7.1 cygwin installed on Windows 2000. We understand that the maximum connections that can be set is 64 in Postgresql 7.1 version. But our application is installed in 8 / 10 PC or more than

Re: [PERFORM] shared_buffer optimization

Quoth [EMAIL PROTECTED] (Ruben Rubio): > Hi, I have a question with shared_buffer. > > Ok, I have a server with 4GB of RAM > - > # cat /proc/meminfo > MemTotal: 4086484 kB > [...] > - > > So, if I want to, for example, shared_buffer to take 3 GB of RAM then > shared_buffer would be 393

Re: [PERFORM] 64-bit vs 32-bit performance ... backwards?

Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Nis Jorgensen) wrote: > J. Andrew Rogers wrote: > >> We have been using PostgreSQL on Opteron servers almost since the >> Opteron was first released, running both 32-bit and 64-bit versions of >> Linux. Both 32-bit and 64-bit versions

Re: [PERFORM] 64-bit vs 32-bit performance ... backwards?

Martha Stewart called it a Good Thing when [EMAIL PROTECTED] ("Alex Turner") wrote: > Anyone who has tried x86-64 linux knows what a royal pain in the ass > it is.   They didn't do anything sensible, like just make the whole > OS 64 bit, no, they had to split it up, and put 64-bit libs in a new >

Re: [PERFORM] 64-bit vs 32-bit performance ... backwards?

[EMAIL PROTECTED] (Anthony Presley) wrote: > Hi all! > > I had an interesting discussion today w/ an Enterprise DB developer and > sales person, and was told, twice, that the 64-bit linux version of > Enterprise DB (which is based on the 64-bit version of PostgreSQL 8.1) > is SIGNIFICANTLY SLOWER t

Re: [PERFORM] Stored Procedure Performance

[EMAIL PROTECTED] ("Simon Dale") wrote: > Event with the planning removed, the function still > performs > significantly slower than the raw SQL. Is that normal or am I doing something > wrong > with the creation or calling of the > function? I'd expect this, yes. You're doing something via "st

Re: [PERFORM] Scaling up PostgreSQL in Multiple CPU / Dual Core

Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Scott Marlowe) wrote: > On Thu, 2006-03-23 at 10:43, Joshua D. Drake wrote: >> > Has someone been working on the problem of splitting a query into pieces >> > and running it on multiple CPUs / multiple machines? Yes. Bizgress has >> >

Re: [PERFORM] Scaling up PostgreSQL in Multiple CPU / Dual Core Powered Servers

[EMAIL PROTECTED] ("Jojo Paderes") wrote: > I'd like to know if the latest PostgreSQL release can scale up by > utilizing multiple cpu or dual core cpu to boost up the sql > executions. > > I already do a research on the PostgreSQL mailing archives and only > found old threads dating back 2000. A l

Re: [PERFORM] vacuum, analyze and reindex

Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Javier Somoza) would write: >     Hi all >     I've a question about vacuuming, ... >     Vacuum: cleans out obsolete and deleted registers... >     Analyze:  update statistics for the planner >    

Re: [PERFORM] Reliability recommendations

After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] ("Joshua D. Drake") belched out: > Jeremy Haile wrote: >> We are a small company looking to put together the most cost effective >> solution for our production database environment. Currently in >> production Postgres 8.1 is running on t

Re: [PERFORM] Default autovacuum settings too conservative

> Jim C. Nasby wrote: >> On Tue, Feb 07, 2006 at 01:39:34PM +0100, Markus Schaber wrote: >> >>>Hi, Jim, >>> >>>Jim C. Nasby wrote: >>> >>> What we really need is a replacement for vacuum_delay that takes PostgreSQL generated IO activity into account... >>> >>>There are also other ideas whic

Re: [PERFORM] Default autovacuum settings too conservative

> On Wed, Feb 01, 2006 at 04:37:07PM -0500, Matthew T. O'Connor wrote: >> I think the default settings should be designed to minimize the impact >> autovacuum has on the system while preventing the system from ever >> getting wildly bloated (also protect xid wraparound, but that doesn't >> have

Re: [PERFORM] Autovacuum / full vacuum

> did you read my post? In the first part I explained why I don't want > to increase the FSM that much. No, you didn't. You explained *that* you thought you didn't want to increase the FSM. You didn't explain why. FSM expansion comes fairly cheap, and tends to be an effective way of eliminating

Re: [PERFORM] Autovacuum / full vacuum

> I'm curious as to why autovacuum is not designed to do full vacuum. Because that's terribly invasive due to the locks it takes out. Lazy vacuum may chew some I/O, but it does *not* block your application for the duration. VACUUM FULL blocks the application. That is NOT something that anyone

Re: [PERFORM] new to postgres (and db management) and performance already a problem :-(

>>> in our db system (for a website), i notice performance boosts after >>> a vacuum >>> full. but then, a VACUUM FULL takes 50min+ during which the db is >>> not really >>> accessible to web-users. is there another way to perform >>> maintenance tasks >>> AND leaving the db fully operable and acce

Re: [PERFORM] SAN/NAS options

> Following up to myself again... > > On Wed, 14 Dec 2005, Charles Sprickman wrote: > >> Hello all, >> >> Supermicro 1U w/SCA backplane and 4 bays >> 2x2.8 GHz Xeons >> Adaptec 2015S "zero channel" RAID card > > I don't want to throw away the four machines like that that we have. > I do want to thr

Re: [PERFORM] Need for speed

>> Ulrich Wisser wrote: >> > >> > one of our services is click counting for on line advertising. We do >> > this by importing Apache log files every five minutes. This results in a >> > lot of insert and delete statements. > ... >> If you are doing mostly inserting, make sure you are in a transact

Re: [PERFORM] Mount database on RAM disk?

> On 8 Jul 2005, at 20:21, Merlin Moncure wrote: >> ditto windows. >> >> Files cached in memory are slower than reading straight from memory >> but not nearly enough to justify reserving memory for your use. In >> other words, your O/S is a machine with years and years of >> engineering designed b

Re: [PERFORM] Need help to decide Mysql vs Postgres

In the last exciting episode, [EMAIL PROTECTED] (Amit V Shah) wrote: >> I am all for postgres at this point, however just want to know why I am >> getting opposite results !!! Both DBs are on the same machine > >> Why do you say "opposite results" ? > > Please pardon my ignorance, but from wha

Re: [PERFORM] Insert slow down on empty database

In an attempt to throw the authorities off his trail, "Morgan" <[EMAIL PROTECTED]> transmitted: > At first I was using straight insert statments, and although they > were a bit slower than the prepared statments(after the restablished > connection) they never ran into this problem with the databas

Re: [PERFORM] Recommendations for set statistics

After a long battle with technology, [EMAIL PROTECTED] (Sebastian Hennebrueder), an earthling, wrote: > I could not find any recommandations for the level of set statistics > and what a specific level does actually mean. > What is the difference between 1, 50 and 100? What is recommanded for > a t

Re: [PERFORM] Joel's Performance Issues WAS : Opteron vs Xeon

Martha Stewart called it a Good Thing when [EMAIL PROTECTED] ("Merlin Moncure") wrote: >> In practice, we have watched Windows evolve in such a fashion with >> respect to multiuser support, and, in effect, it has never really >> gotten it. Microsoft started by hacking something on top of MS-DOS,

Re: [PERFORM] Joel's Performance Issues WAS : Opteron vs Xeon

Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] ("Joel Fradkin") would write: > I am just testing the water so to speak, if it cant handle single > user tests then multiple user tests are kind of a waste of time. I would suggest that if multi-user functionality is needed, then starting

Re: [PERFORM] Opteron vs Xeon

Quoth [EMAIL PROTECTED] (Christian Sander Røsnes): > On Wednesday 20 April 2005 17:50, Bruce Momjian wrote: >> Anjan Dave wrote: >> > In terms of vendor specific models - >> > >> > Does anyone have any good/bad experiences/recommendations for a >> > 4-way Opteron from Sun (v40z, 6 internal drives)

Re: [PERFORM] plperl vs plpgsql

After a long battle with technology, [EMAIL PROTECTED] (Alex), an earthling, wrote: > Christopher Browne wrote: >>After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] (Alex) belched >>out: >>>i am thinking about swiching to plperl as it seems to me much m

Re: [PERFORM] plperl vs plpgsql

After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] (Alex) belched out: > i am thinking about swiching to plperl as it seems to me much more > flexible and easier to create functions. > > what is the recommended PL for postgres? or which one is most widely > used / most popular? > is there

Re: [PERFORM] What about utility to calculate planner cost constants?

Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Greg Stark) wrote: > I don't think it would be very hard at all actually. > > It's just a linear algebra problem with a bunch of independent > variables and a system of equations. Solving for values for all of > them is a straightforward

Re: [PERFORM] Peformance Tuning Opterons/ Hard Disk Layout

[EMAIL PROTECTED] ("Bruno Almeida do Lago") wrote: > Is there a real limit for max_connections? Here we've an Oracle server with > up to 1200 simultaneous conections over it! > > "max_connections: exactly like previous versions, this needs to be set to > the actual number of simultaneous connection

Re: [PERFORM] is pg_autovacuum so effective ?

only really meaningful if you're moving towards the "equilibrium point" where the FSM is large enough to cope with the growth between VACUUM cycles. VACUUM FULL pushes the system away from equilibrium, thereby making FSM estimates less useful. -- "cbbrowne"

Re: [PERFORM] is pg_autovacuum so effective ?

s; just plain VACUUMs. I revised cron scripts yet again today to do hourly and "4x/day" vacuums of certain tables in some of our systems where we know they need the attention. I didn't schedule any VACUUM FULLs; it's unnecessary, and would lead directly t

Re: [PERFORM] Effects of IDLE processes

After a long battle with technology, Gaetano Mendola <[EMAIL PROTECTED]>, an earthling, wrote: > JM wrote: >> Hi ALL, >> >> I was wondering if there is a DB performance reduction if >> there are a lot of IDLE processes. >> >> 30786 ?S 0:00 postgres: user1 gmadb 10.10.10.1 idle

Re: [PERFORM] seq scan cache vs. index cache smackdown

In the last exciting episode, [EMAIL PROTECTED] ("Merlin Moncure") wrote: >> It seems inevitable that Postgres will eventually eliminate that >> redundant layer of buffering. Since mmap is not workable, that >> means using O_DIRECT to read table and index data. > > What about going the other way an

Re: [PERFORM] seq scan cache vs. index cache smackdown

The world rejoiced as [EMAIL PROTECTED] (Mark Aufflick) wrote: > Hi All, > > I have boiled my situation down to the following simple case: > (postgres version 7.3) > > * Query 1 is doing a sequential scan over a table (courtesy of field > ILIKE 'foo%') and index joins to a few others > * Query 2 is

Re: [PERFORM] estimated rows vs. actual rows

After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] (Jaime Casanova) belched out: > On Sun, 13 Feb 2005 13:41:09 -0800, Josh Berkus wrote: >> Jaime, >> >> > Why is this query using a seq scan rather than a index scan? >> >> Because it thinks a seq scan will be faster. >> > I will sugge

Re: [PERFORM] Benchmark

Oops! [EMAIL PROTECTED] ("Merlin Moncure") was seen spray-painting on a wall: > Instead of measuring transactions/second, let's put everything in terms > of transactions/dollar. This will make it quite easy to determine which > database is which from the results. Since postgresql is free and woul

Re: [PERFORM] Performance Tuning

The world rejoiced as [EMAIL PROTECTED] (PFC) wrote: >> As a side note, I learned something very interesting for our >> developers here. >> We had been doing a drop database and then a reload off a db dump >> from our >> live server for test data. This takes 8-15 minutes depending on the >> serv

Re: [PERFORM] High end server and storage for a PostgreSQL OLTP system

pgman@candle.pha.pa.us (Bruce Momjian) wrote: > William Yu wrote: >> > Well, that would give you the most benefit, but the memory >> > bandwidth is still greater than on a Xeon. There's really no >> > issue with 64 bit if you're using open source software; it all >> > compiles for 64 bits and you'r

Re: [PERFORM] Bitmap indexes

es that might do joins on id_column where your query has the qualifiers "where field_a = 'Y'" or "where field_a = 'N'". That's not going to provide a generalized answer to "star queries," but it is an immediate answer for some cases. -- "cbb

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

e idea of using "pg_dump --data-only" against a subscriber node to get you the data without putting a load on the origin. And then pulling the schema from the origin, which oughtn't be terribly expensive there. -- "cbbrowne","@","ca.afilias.info" &l

Re: [PERFORM] [SQL] OFFSET impact on Performance???

In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] ("Merlin Moncure") transmitted: > Alex wrote: >> How do you create a temporary view that has only a small subset of the >> data from the DB init? (Links to docs are fine - I can read ;). My >> query isn't all that complex, a

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Steve Atkins) would write: > As a bit of obPostgresql, though... While the registry for .org is > run on Postgresql, the actual DNS is run on Oracle. That choice was > driven by the availability of multi-master replication. > > Like many o

[PERFORM] Cheaper VACUUMing

A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Greg Stark) wrote: > Dawid Kuroczko <[EMAIL PROTECTED]> writes: > >> Quick thought -- would it be to possible to implement a 'partial VACUUM' >> per analogiam to partial indexes? > > No. > > But it gave me another idea. Perhaps equally

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

After a long battle with technology, [EMAIL PROTECTED] (Hervé Piedvache), an earthling, wrote: > Joshua, > > Le Jeudi 20 Janvier 2005 15:44, Joshua D. Drake a écrit : >> Hervé Piedvache wrote: >> > >> >My company, which I actually represent, is a fervent user of PostgreSQL. >> >We used to make all

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

Quoth Ron Mayer <[EMAIL PROTECTED]>: > Merlin Moncure wrote: >> ...You need to build a bigger, faster box with lots of storage... >> Clustering ... B: will cost you more, not less > > > Is this still true when you get to 5-way or 17-way systems? > > My (somewhat outdated) impression is that up to a

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

In the last exciting episode, [EMAIL PROTECTED] (Hervé Piedvache) wrote: > Le Jeudi 20 Janvier 2005 16:05, Joshua D. Drake a écrit : >> Christopher Kings-Lynne wrote: >> >>> Or you could fork over hundreds of thousands of dollars for Oracle's >> >>> RAC. >> >> >> >> No please do not talk about thi

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Hervé Piedvache) transmitted: > Le Jeudi 20 Janvier 2005 15:24, Christopher Kings-Lynne a écrit : >> > Is there any solution with PostgreSQL matching these needs ... ? >> >> You want: http://www.slony.info/ >> >> > Do we have

Re: [PERFORM] Best filesystem for PostgreSQL Database Cluster under Linux

After a long battle with technology, "Pete de Zwart" <[EMAIL PROTECTED]>, an earthling, wrote: > Greetings to one and all, > > I've been trying to find some information on selecting an optimal > filesystem setup for a volume that will only contain a PostgreSQL Database > Cluster under Linux.

Re: [PERFORM] which dual-CPU hardware/OS is fastest for PostgreSQL?

Xeon sux pretty bad... > Linux or FreeBSD or _?_ The killer question won't be of what OS is "faster," but rather of what OS better supports the fastest hardware you can get your hands on. We tried doing some FreeBSD benchmarking on a quad-Opteron box, only to discover that the fibrechannel con

Re: [PERFORM] which dual-CPU hardware/OS is fastest for PostgreSQL?

Quoth [EMAIL PROTECTED] (Miles Keaton): > I'm sorry if there's a URL out there answering this, but I couldn't > find it. > > For those of us that need the best performance possible out of a > dedicated dual-CPU PostgreSQL server, what is recommended? > > AMD64/Opteron or i386/Xeon? Xeon sux pretty

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

Oops! [EMAIL PROTECTED] (Pierre-Frédéric Caillaud) was seen spray-painting on a wall: >> The .NET Runtime will be a part of the next MS SQLServer engine. You >> will be able to have C# as a pl in the database engine with the next >> version of MSSQL. That certainly will be something to think about

Re: [PERFORM] Very Bad Performance.

Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Pallav Kalva) wrote: >> Then you have to look at individual slow queries to determine why >> they are slow, fortunately you are running 7.4 so you can set >> log_min_duration to some number like 1000ms and then >> try to analyze why tho

Re: [PERFORM] Which is more efficient?

A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] ("Mike G.") wrote: > Hi, > > I have data that I am taking from 2 tables, pulling out specific columns and > inserting into one table. > > Is it more efficient to do: > a) insert into x > select z from y; > insert into x > s

Re: [PERFORM] Trying to create multi db query in one large queries

The world rejoiced as [EMAIL PROTECTED] (Josh Berkus) wrote: > Hasnul, > >> My question is if there is a query design that would query multiple >> server simultaneously.. would that improve the performance? > > Not without a vast amounts of infrastructure coding. You're > basically talking about w

Re: [PERFORM] scaling beyond 4 processors

In the last exciting episode, [EMAIL PROTECTED] wrote: > Hello everyone! > > Since our current Postgres server, a quad Xeon system, finally can't > keep up with our load anymore we're ready to take the next step. > > So the question is: Has anyone experiences with running Postgres on > systems with

Re: [PERFORM] scaling beyond 4 processors

The perhaps odd thing is that just about any alternative to quad-Xeon is likely to be _way_ better. There are some context switching problems that lead to it being remarkably poorer than you'd expect. Throw in less-than ideal performance of the PAE memory addressing system and it seems oddly cripp

Re: [PERFORM] Improve BULK insertion

In the last exciting episode, [EMAIL PROTECTED] (Grupos) wrote: > Hi ! > > I need to insert 500.000 records on a table frequently. It´s a bulk > insertion from my applicatoin. > I am with a very poor performance. PostgreSQL insert very fast until > the tuple 200.000 and after it the insertion start

Re: [PERFORM] DB2 feature

Clinging to sanity, [EMAIL PROTECTED] (Pailloncy Jean-Gérard) mumbled into her beard: > I see this article about DB2 > http://www-106.ibm.com/developerworks/db2/library/techarticle/dm > -0411rielau/?ca=dgr-lnxw06SQL-Speed > > The listing 2 example: > 1 SELECT D_TAX, D_NEXT_O_ID > 2 INTO :dist

Re: [PERFORM] pg replication tools?

Clinging to sanity, [EMAIL PROTECTED] ("Joshua D. Drake") mumbled into her beard: > sarlav kumar wrote: > >> Hi all, >> Which is the best available PG replication tool in market now? > > There is no "best", there is only best for your situation. The two > most supported are: > > >> * Mammoth

Re: [PERFORM] [dspam-users] Postgres vs. MySQL

Martha Stewart called it a Good Thing when [EMAIL PROTECTED] ("Casey Allen Shobe") wrote: > I posted about this a couple days ago on dspam-dev... > > I am using DSpam with PostgreSQL, and like you discovered the horrible > performance. The reason is because the default PostgreSQL query planner >

Re: [PERFORM] Checking = with timestamp field is slow

After a long battle with technology, [EMAIL PROTECTED] (Antony Paul), an earthling, wrote: > Hi all, >I have a table which have more than 20 records. I need to get > the records which matches like this > > where today::date = '2004-11-05'; > > This is the only condition in the query. There

Re: [PERFORM] Anything to be gained from a 'Postgres Filesystem'?

After a long battle with technology, [EMAIL PROTECTED] (Simon Riggs), an earthling, wrote: > On Thu, 2004-11-04 at 15:47, Chris Browne wrote: > >> Another thing that would be valuable would be to have some way to say: >> >> "Read this data; don't bother throwing other data out of the cache >>

Re: [PERFORM] Anything to be gained from a 'Postgres Filesystem'?

In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Markus Schaber) transmitted: > We should create a list of those needs, and then communicate those > to the kernel/fs developers. Then we (as well as other apps) can > make use of those features where they are available, and u

Re: [PERFORM] First set of OSDL Shared Mem scalability results, some wierdness ...

Quoth [EMAIL PROTECTED] ("Simon Riggs"): > I say this: ARC in 8.0 PostgreSQL allows us to sensibly allocate as > large a shared_buffers cache as is required by the database > workload, and this should not be constrained to a small percentage > of server RAM. I don't think that this particularly fo

Re: [PERFORM] Which plattform do you recommend I run PostgreSQL for best performance?

In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] transmitted: > I am doing a comparison between MySQL and PostgreSQL. > > In the MySQL manual it says that MySQL performs best with Linux 2.4 with > ReiserFS on x86. Can anyone official, or in the know, give similar > informatio

Re: [PERFORM] IBM P-series machines (was: Excessive context

[EMAIL PROTECTED] (Rod Taylor) wrote: > On Mon, 2004-10-11 at 13:38, Andrew Sullivan wrote: >> On Tue, Oct 05, 2004 at 09:47:36AM -0700, Josh Berkus wrote: >> > As long as you're on x86, scaling outward is the way to go. If >> > you want to continue to scale upwards, ask Andrew Sullivan about >> >

Re: [PERFORM] First set of OSDL Shared Mem scalability results, some wierdness ...

[EMAIL PROTECTED] (Josh Berkus) wrote: > I've been trying to peg the "sweet spot" for shared memory using > OSDL's equipment. With Jan's new ARC patch, I was expecting that > the desired amount of shared_buffers to be greatly increased. This > has not turned out to be the case. That doesn't surp

Re: [PERFORM] Data Warehouse Reevaluation - MySQL vs Postgres --

In the last exciting episode, [EMAIL PROTECTED] (Joe Conway) wrote: > That's exactly what we're doing, but using inherited tables instead of > a union view. With inheritance, there is no need to rebuild the view > each time a table is added or removed. Basically, in our application, > tables are pa

Re: [PERFORM] Data Warehouse Reevaluation - MySQL vs Postgres -- merge tables

[EMAIL PROTECTED] ("Simon Riggs") wrote: > The main point is that the constant placed in front of each table > must in some way relate to the data, to make it useful in > querying. If it is just a unique constant, chosen at random, it > won't do much for partition elimination. It just struck me -

Re: [PERFORM] Data Warehouse Reevaluation - MySQL vs Postgres -- merge tables

A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Mark Cotner) wrote: > Agreed, I did some preliminary testing today and am very impressed. > I wasn't used to running analyze after a data load, but once I did > that everything was snappy. Something worth observing is that this is true

Re: [PERFORM] Data Warehouse Reevaluation - MySQL vs Postgres -- merge tables

The world rejoiced as Mischa Sandberg <[EMAIL PROTECTED]> wrote: > Mark Cotner wrote: >> Requirements: >> Merge table definition equivalent. We use these >> extensively. > Looked all over mysql.com etc, and afaics merge table is indeed > exactly a view of a union-all. Is that right? > PG support

Re: [PERFORM] fsync vs open_sync

The world rejoiced as [EMAIL PROTECTED] ("Merlin Moncure") wrote: > Ok, you were right. I made some tests and NTFS is just not very > good in the general case. I've seen some benchmarks for Reiser4 > that are just amazing. Reiser4 has been sounding real interesting. The killer problem is thus:

Re: [PERFORM] Replication: Slony-I vs. Mammoth Replicator vs. ?

Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] ("Joshua D. Drake") would write: > I hope you understand that I, in no way have ever suggested > (purposely) anything negative about Slony. Only that I believe they > serve different technical solutions. Stipulating that I may have some bi

Re: [PERFORM] Bulk Insert and Index use

In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Rudi Starcevic) transmitted: > A minute for your thoughts and/or suggestions would be great. Could you give a more concrete example? E.g. - the DDL for the table(s), most particularly. At first guess, I think you're worryi

Re: [PERFORM] my boss want to migrate to ORACLE

After a long battle with technology, [EMAIL PROTECTED] ("Stephane Tessier"), an earthling, wrote: > I think with your help guys I'll do it! > > I'm working on it! > > I'll work on theses issues: > > we have space for more ram(we use 2 gigs on possibility of 3 gigs) That _may_ help; not completely

Re: [PERFORM] vacuum full 100 mins plus?

A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Patrick Hatcher) wrote: > Answered my own question. I gave up the vacuum full after 150 mins. I was > able to export to a file, vacuum full the empty table, and reimport in less > than 10 mins. I suspect the empty item pointers and t

Re: [PERFORM] Working on huge RAM based datasets

Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Jan Wieck) wrote: > On 7/9/2004 10:16 AM, Merlin Moncure wrote: >>> What is it about the buffer cache that makes it so unhappy being >>> able to hold everything? I don't want to be seen as a cache hit >>> fascist, but isn't it just bette

Re: [PERFORM] Working on huge RAM based datasets

Quoth [EMAIL PROTECTED] ("Andy Ballingall"): > This is the future, isn't it? Each year, a higher percentage of DB > applications will be able to fit entirely in RAM, and that percentage is > going to be quite significant in just a few years. The disk system gets > relegated to a data preload on sta

Re: [PERFORM] Postgres over Linux NBD or NFS

In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Andrew Rawnsley) transmitted: > On Jun 21, 2004, at 2:02 PM, Andrew Hammond wrote: >> We're looking for an alternative to fiber-channel disk arrays for mass >> storage. One of the ideas that we're exploring would involve havi

Re: [PERFORM] [PERFORMANCE] slow small delete on large table

After a long battle with technology, [EMAIL PROTECTED] ("Ed L."), an earthling, wrote: > On Monday February 23 2004 10:23, Tom Lane wrote: >> "Ed L." <[EMAIL PROTECTED]> writes: >> Depending on the size of mytable, you might need an "ANALYZE doomed" >> in there, but I'm suspecting not. A quick exp

Re: [PERFORM] [PERFORMANCE] slow small delete on large table

[EMAIL PROTECTED] ("Ed L.") wrote: > A 7.3.4 question... > > I want to "expire" some data after 90 days, but not delete too > much at once so as not to overwhelm a system with precariously > balanced disk I/O and on a table with millions of rows. If I > could say it the way I think for a simple e

Re: [PERFORM] tuning for AIX 5L with large memory

Clinging to sanity, [EMAIL PROTECTED] (Dan Harris) mumbled into her beard: > I will soon have at my disposal a new IBM pSeries server. The main > mission for this box will be to serve several pg databases. I have > ordered 8GB of RAM and want to learn the best way to tune pg and AIX > for this co

Re: [PERFORM] Wierd context-switching issue on Xeon

In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Tom Lane) transmitted: > ObQuote: "Research is what I am doing when I don't know what I am > doing." - attributed to Werner von Braun, but has anyone got a > definitive reference?

Re: [PERFORM] Long running queries degrade performance

A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Mike Nolan) wrote: >> We have a web app with a postgres backend. Most queries have subsecond >> response times through the web even with high usage. Every once in awhile >> someone will run either an ad-hoc query or some other long

Re: [PERFORM] pg_xlog on same drive as OS

In the last exciting episode, [EMAIL PROTECTED] wrote: > greetings! > on a dedicated pgsql server is putting pg_xlog > in drive as OS almost equivalent to putting on a seperate > drive? > > in both case the actual data files are in a seperate > drive. Well, if the OS drive is relatively inactive,

Re: [PERFORM] Scaling further up

After a long battle with technology, [EMAIL PROTECTED] (Josh Berkus), an earthling, wrote: >> Other than the disks, I am curious what other people are using in >> terms of the horsepower needed. The Quad server has been keeping >> up, but we are expecting quite high loads in the near future, and I

Re: [PERFORM] Tables on multiple disk drives

[EMAIL PROTECTED] (Konstantin Tokar) wrote: > Hi! > Does PostgreSQL allow to create tables and indices of a single > database on multiple disk drives with a purpose of increase > performance as Oracle database does? If a symbolic reference is the > only method then the next question is: how can it

Re: [PERFORM] select count(*) from anIntColumn where int_value = 0;

Oops! [EMAIL PROTECTED] (Pavel Stehule) was seen spray-painting on a wall: > > Regards > Pavel Stehule > > On Wed, 11 Feb 2004, David Teran wrote: > >> Hi >> >> we have a table with about 4 million rows. One column has an int value, >> there is a btree index on it. We tried to execute the followi

Re: [PERFORM] 7.3 vs 7.4 performance

In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] ("Carlos Eduardo Smanioto") transmitted: >> I did some heavy-transaction-oriented tests recently on somewhat >> heftier quad-Xeon hardware, and found little difference between 2.4 >> and 2.6, and a small-but-quite-repeatable a

Re: [PERFORM] 7.3 vs 7.4 performance

Oops! [EMAIL PROTECTED] (Orion Henry) was seen spray-painting on a wall: > I've done some testing of 7.3.4 vs 7.4.1 and found 7.4.1 to be 20%-30% > slower than 7.3.4. Is this common knowledge or am I just unlucky with > my query/data selection? That seems unusual; the opposite seems more typical

Re: [PERFORM] Compile Vs RPMs

stom compiling will have any substantial effect on I/O-bound processing. -- output = reverse("ofni.smrytrebil" "@" "enworbbc") <http://dev6.int.libertyrms.com/> Christopher Browne (416) 646 3304 x124 (land) ---(end of broadcast)---

  1   2   >