Re: [PERFORM] performance hit for replication

[EMAIL PROTECTED] ("Joshua D. Drake") writes: >>So, my question is this: My server currently works great, >>performance wise. I need to add fail-over capability, but I'm >>afraid that introducing a stressful task such as replication will >>hurt my server's performance. Is there any foundation to m

Re: [PERFORM] Index bloat problem?

josh@agliodbs.com (Josh Berkus) writes: > Bill, > >> What about if an out-of-the-ordinary number of rows >> were deleted (say 75% of rows in the table, as opposed >> to normal 5%) followed by a 'VACUUM ANALYZE'?  Could >> things get out of whack because of that situation? > > Yes. You'd want to ru

Re: [PERFORM] How can an index be larger than a table

josh@agliodbs.com (Josh Berkus) writes: > David, > >> What also seems weird to me is that the control table has some unique >> indexes created on it, but the data_upate_events table just has a unique >> constraint.  Will postgres use an index in the background to enforce >> this constraint? > > If

Re: [PERFORM] batch inserts are "slow"

[EMAIL PROTECTED] (Christopher Petrilli) writes: > On 5/2/05, Tim Terlegård <[EMAIL PROTECTED]> wrote: >> Howdy! >> >> I'm converting an application to be using postgresql instead of >> oracle. There seems to be only one issue left, batch inserts in >> postgresql seem significant slower than in o

Re: [PERFORM] PGSQL Capacity

[EMAIL PROTECTED] writes: > How can i know a capacity of a pg database ? > How many records my table can have ? > I saw in a message that someone have 50 000 records it's possible in a table ? > (My table have 8 string field (length 32 car)). > Thanks for your response. The capacity is much more l

Re: [PERFORM] Prefetch - OffTopic

[EMAIL PROTECTED] ("Mohan, Ross") writes: > for time-series and "insane fast", nothing beats kdB, I believe > > www.kx.com ... Which is well and fine if you're prepared to require that all of the staff that interact with data are skilled APL hackers. Skilled enough that they're all ready to leap

Re: [PERFORM] Mount database on RAM disk?

[EMAIL PROTECTED] (Stuart Bishop) writes: > I'm putting together a road map on how our systems can scale as our > load increases. As part of this, I need to look into setting up some > fast read only mirrors of our database. We should have more than > enough RAM to fit everything into memory. I wou

Re: [PERFORM] Cheap RAM disk?

[EMAIL PROTECTED] (John A Meinel) writes: > I saw a review of a relatively inexpensive RAM disk over at > anandtech.com, the Gigabyte i-RAM > http://www.anandtech.com/storage/showdoc.aspx?i=2480 And the review shows that it's not *all* that valuable for many of the cases they looked at. > Basical

Re: [PERFORM] Cheap RAM disk?

[EMAIL PROTECTED] ("Jeffrey W. Baker") writes: > I haven't tried this product, but the microbenchmarks seem truly > slow. I think you would get a similar benefit by simply sticking a > 1GB or 2GB DIMM -- battery-backed, of course -- in your RAID > controller. Well, the microbenchmarks were pretty

Re: [PERFORM] Performance for relative large DB

"tobbe" <[EMAIL PROTECTED]> writes: > The company that I'm working for are surveying the djungle of DBMS > since we are due to implement the next generation of our system. > > The companys buissnes is utilizing the DBMS to store data that are > accessed trough the web at daytime (only SELECTs, some

Re: [PERFORM] Caching by Postgres

[EMAIL PROTECTED] (Donald Courtney) writes: > I mean well with this comment - > This whole issue of data caching is a troubling issue with postreSQL > in that even if you ran postgreSQL on a 64 bit address space > with larger number of CPUs you won't see much of a scale up > and possibly even a dr

Re: [PERFORM] Caching by Postgres

[EMAIL PROTECTED] (Michael Stone) writes: > On Tue, Aug 23, 2005 at 12:38:04PM -0700, Josh Berkus wrote: >> which have a clear and measurable effect on performance and are >> fixable without bloating the PG code. Some of these issues (COPY >> path, context switching > > Does that include increasin

Re: [PERFORM] Read/Write block sizes

[EMAIL PROTECTED] (Jignesh Shah) writes: >> Does that include increasing the size of read/write blocks? I've >> noticedthat with a large enough table it takes a while to do a >> sequential scan, even if it's cached; I wonder if the fact that it >> takes a million read(2) calls to get through an 8G

Re: [PERFORM] Performance for relative large DB

"tobbe" <[EMAIL PROTECTED]> writes: > Hi Chris. > > Thanks for the answer. > Sorry that i was a bit unclear. > > 1) We update around 20.000 posts per night. No surprise there; I would have been surprised to see 100/nite or 6M/nite... > 2) What i meant was that we suspect that the DBMS called Perv

Re: [PERFORM] Read/Write block sizes

[EMAIL PROTECTED] (Steve Poe) writes: > Chris, > > Unless I am wrong, you're making the assumpting the amount of time spent > and ROI is known. Maybe those who've been down this path know how to get > that additional 2-4% in 30 minutes or less? > > While each person and business' performance gains

Re: [PERFORM] Read/Write block sizes

[EMAIL PROTECTED] (Ron) writes: > At 03:45 PM 8/25/2005, Josh Berkus wrote: >> > Ask me sometime about my replacement for GNU sort. Â It uses the >> > same sorting algorithm, but it's an order of magnitude faster due >> > to better I/O strategy. Â Someday, in my infinite spare time, I >> > hope to

Re: [PERFORM] When to do a vacuum for highly active table

[EMAIL PROTECTED] (Markus Benne) writes: > We have a highly active table that has virtually all > entries updated every 5 minutes. Typical size of the > table is 50,000 entries, and entries have grown fat. > > We are currently vaccuming hourly, and towards the end > of the hour we are seeing degra

Re: [PERFORM] When to do a vacuum for highly active table

[EMAIL PROTECTED] ("Rigmor Ukuhe") writes: >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:pgsql-performance- >> [EMAIL PROTECTED] On Behalf Of Markus Benne >> Sent: Wednesday, August 31, 2005 12:14 AM >> To: pgsql-performance@postgresql.org >> Subject: [PERFORM] When to do a vacu

Re: [PERFORM] please comment on cpu 32 bit or 64 bit

[EMAIL PROTECTED] ("wisan watcharinporn") writes: > please help me , > comment on postgresql (8.x.x) performance on cpu AMD, INTEL > and why i should use 32 bit or 64 cpu ? (what the performance difference) Generally speaking, the width of your I/O bus will be more important to performance than th

Re: [PERFORM] VACUUM FULL vs CLUSTER

[EMAIL PROTECTED] (Stef) writes: > Bruno Wolff III mentioned : > => If you have a proper FSM setting you shouldn't need to do vacuum fulls > => (unless you have an older version of postgres where index bloat might > => be an issue). > > What version of postgres was the last version that had > the i

Re: [PERFORM] Advice on RAID card

[EMAIL PROTECTED] ("Joshua D. Drake") writes: > There is a huge advantage to software raid on all kinds of > levels. If you have the CPU then I suggest it. However you will > never get the performance out of software raid on the high level > (think 1 gig of cache) that you would on a software raid

Re: [PERFORM] int2 vs int4 in Postgres

[EMAIL PROTECTED] ("Announce") writes: > I KNOW that I am not going to have anywhere near 32,000+ different > genres in my genre table so why use int4? Would that squeeze a few > more milliseconds of performance out of a LARGE song table query > with a genre lookup? By the way, I see a lot of que

Re: [PERFORM] int2 vs int4 in Postgres

[EMAIL PROTECTED] ("Announce") writes: > I KNOW that I am not going to have anywhere near 32,000+ different > genres in my genre table so why use int4? Would that squeeze a few > more milliseconds of performance out of a LARGE song table query > with a genre lookup? If the field is immaterial in

Re: [PERFORM] Ultra-cheap NVRAM device

[EMAIL PROTECTED] (Dan Harris) writes: > On Oct 3, 2005, at 5:02 AM, Steinar H. Gunderson wrote: > >> I thought this might be interesting, not the least due to the >> extremely low >> price ($150 + the price of regular DIMMs): > > Replying before my other post came through.. It looks like their > b

Re: [PERFORM] Status of Opteron vs Xeon

[EMAIL PROTECTED] (Jeff Frost) writes: > 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

Re: [PERFORM] index auto changes after copying data ?

[EMAIL PROTECTED] ("[EMAIL PROTECTED]") writes: > I know in mysql, index will auto change after copying data Of > course, index will change after inserting a line in postgresql, but > what about copying data? Do you mean, by this, something like... "Are indexes affected by loading data using the

Re: [PERFORM] 15,000 tables

Michael Riess <[EMAIL PROTECTED]> writes: >> On 12/1/05, Michael Riess <[EMAIL PROTECTED]> wrote: >>> we are currently running a postgres server (upgraded to 8.1) which >>> has one large database with approx. 15,000 tables. Unfortunately >>> performance suffers from that, because the internal table

Re: [PERFORM] One table is very slow, but replicated table (same data) is fine

[EMAIL PROTECTED] writes: > If anyone knows what may cause this problem, or has any other ideas, I > would be grateful. Submit the command "VACUUM ANALYZE VERBOSE locations;" on both servers, and post the output of that. That might help us tell for sure whether the table is bloated (and needs VAC

Re: [PERFORM] New to PostgreSQL, performance considerations

[EMAIL PROTECTED] ("Daniel van Ham Colchete") writes: > You are right Christopher. > > Okay. Let's solve this matter. > > What PostgreSQL benchmark software should I use??? pgbench is one option. There's a TPC-W at pgFoundry (). There's the Open Sour

Re: [PERFORM] Caching in PostgreSQL

[EMAIL PROTECTED] writes: > Can anybody tell me how can I implement data Caching in the > shared memory using PostgreSQL. PostgreSQL already does that. Implementing this functionality is rather tricky: Between version 7.4 and now, it has seen *massive* change which has required a great deal

Re: [PERFORM] Configuration Advice

[EMAIL PROTECTED] (Steve) writes: > I'm wondering what we can do to make > this better if anything; would it be better to leave the indexes on? > It doesn't seem to be. Definitely NOT. Generating an index via a bulk sort is a LOT faster than loading data into an index one tuple at a time. We s

Re: [PERFORM] What`s wrong with JFS configuration?

[EMAIL PROTECTED] (Paweł Gruszczyński) writes: > To test I use pgBench with default database schema, run for 25, 50, 75 > users at one time. Every test I run 5 time to take average. > Unfortunetly my result shows that ext is fastest, ext3 and jfs are > very simillar. I can understand that ext2 with

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

[EMAIL PROTECTED] (Michael Stone) writes: > 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 en

Re: [PERFORM] Maintenance question / DB size anomaly...

[EMAIL PROTECTED] (Kurt Overberg) writes: > In my investigation of this anomaly, I noticed that the data/ dir on > db1 (the master) is around 60 Gigs. The data directory on the slaves > is around 25Gb. After about 3 months of head scratching, someone on > the irc channel suggested that it may be

Re: [PERFORM] Very long SQL strings

[EMAIL PROTECTED] (Tom Lane) writes: > PS: for the record, there is a hard limit at 1GB of query text, owing > to restrictions built into palloc. But I think you'd hit other > memory limits or performance bottlenecks before that one. It would be much funnier to set a hard limit of 640K of query t

Re: [PERFORM] best use of an EMC SAN

[EMAIL PROTECTED] (Dave Cramer) writes: > On 11-Jul-07, at 10:05 AM, Gregory Stark wrote: > >> "Dave Cramer" <[EMAIL PROTECTED]> writes: >> >>> Assuming we have 24 73G drives is it better to make one big >>> metalun and carve >>> it up and let the SAN manage the where everything is, or is it >>> b

Re: [PERFORM] performance of postgresql in replication using slony

[EMAIL PROTECTED] (Jeff Davis) writes: > On Thu, 2007-07-26 at 01:44 -0700, angga erwina wrote: >> Hi all, >> whats the benefits of replication by using slony in >> postgresql?? >> My office is separate in several difference place..its >> about hundreds branch office in the difference >> place..so

Re: [PERFORM] Update table performance

[EMAIL PROTECTED] (Mark Makarowsky) writes: > I have a table with 4,889,820 records in it. The > table also has 47 fields. I'm having problems with > update performance. Just as a test, I issued the > following update: > > update valley set test='this is a test' > > This took 905641 ms. Isn't t

Re: [PERFORM] 8.2 Autovacuum BUG ?

[EMAIL PROTECTED] (Pallav Kalva) writes: > Tom Lane wrote: >> Pallav Kalva <[EMAIL PROTECTED]> writes: >> >>> We turned on autovacuums on 8.2 and we have a database which is >>> read only , it is basically a USPS database used only for address >>> lookups (only SELECTS, no updates/deletes/inser

Re: [PERFORM] 8.2 Autovacuum BUG ?

[EMAIL PROTECTED] (Pallav Kalva) writes: > Mark Lewis wrote: >> On Fri, 2007-08-31 at 12:25 -0400, Pallav Kalva wrote: >> >>> Can you please correct me if I am wrong, I want to understand how >>> this works. >>> Based on what you said, it will run autovacuum again when it passes >>> 200M transactio

Re: [PERFORM] Clustered tables improves perfs ?

[EMAIL PROTECTED] (Patrice Castet) writes: > I wonder if clustering a table improves perfs somehow ? > Any example/ideas about that ? > ref : http://www.postgresql.org/docs/8.2/interactive/sql-cluster.html Sometimes. 1. It compacts the table, which may be of value, particularly if the table is n

Re: [PERFORM] performance of like queries

[EMAIL PROTECTED] (Kevin Kempter) writes: > any suggestions for improving "LIKE '%text%'" queries? If you know that the 'text' portion of that query won't change, then you might create a partial index on the boolean condition. That is, create index index_foo_text on my_table (tfield) where (t

Re: [PERFORM] how to improve the performance of creating index

[EMAIL PROTECTED] ("Yinan Li") writes: > I am trying to improve the performance of creating index.:p> > > I've set shared_buffers = 1024MB:p> > >    Effective_cache_size = 1024MB:p> > >    Work_mem = 1GB:p> > >    Maintenance_work_me

Re: [PERFORM] Is DBLINK transactional

cr...@postnewspapers.com.au (Craig Ringer) writes: > On 13/03/2010 5:54 AM, Jeff Davis wrote: >> On Fri, 2010-03-12 at 12:07 -0500, Merlin Moncure wrote: >>> of course. You can always explicitly open a transaction on the remote >>> side over dblink, do work, and commit it at the last possible mom

Re: [PERFORM] mysql to postgresql, performance questions

reeds...@rice.edu ("Ross J. Reedstrom") writes: > http://www.mythtv.org/wiki/PostgreSQL_Support That's a pretty hostile presentation... The page has had two states: a) In 2008, someone wrote up... After some bad experiences with MySQL (data loss by commercial power failure, very bad

Re: [PERFORM] mysql to postgresql, performance questions

t...@sss.pgh.pa.us (Tom Lane) writes: > "Ross J. Reedstrom" writes: >> On Sat, Mar 20, 2010 at 10:47:30PM -0500, Andy Colson wrote: >>> (I added the "and trust" as an after thought, because I do have one very >>> important 100% uptime required mysql database that is running. Its my >>> MythTV b

Re: [PERFORM] PostgreSQL as a local in-memory cache

"jgard...@jonathangardner.net" writes: > My question is how can I configure the database to run as quickly as > possible if I don't care about data consistency or durability? That > is, the data is updated so often and it can be reproduced fairly > rapidly so that if there is a server crash or ran

Re: [PERFORM] PostgreSQL as a local in-memory cache

swamp...@noao.edu (Steve Wampler) writes: > Or does losing WAL files mandate a new initdb? Losing WAL would mandate initdb, so I'd think this all fits into the set of stuff worth putting onto ramfs/tmpfs. Certainly it'll all be significant to the performance focus. -- select 'cbbrowne' || '@' ||

Re: [PERFORM] Testing Sandforce SSD

g...@2ndquadrant.com (Greg Smith) writes: > Yeb Havinga wrote: >> * What filesystem to use on the SSD? To minimize writes and maximize >> chance for seeing errors I'd choose ext2 here. > > I don't consider there to be any reason to deploy any part of a > PostgreSQL database on ext2. The potential

Re: [PERFORM] Testing Sandforce SSD

j...@commandprompt.com ("Joshua D. Drake") writes: > On Sat, 2010-07-24 at 16:21 -0400, Greg Smith wrote: >> Greg Smith wrote: >> > Note that not all of the Sandforce drives include a capacitor; I hope >> > you got one that does! I wasn't aware any of the SF drives with a >> > capacitor on them

Re: [PERFORM] GPU Accelerated Sorting

david_l...@boreham.org (David Boreham) writes: > Feels like I fell through a worm hole in space/time, back to inmos in > 1987, and a guy from marketing has just > walked in the office going on about there's a customer who wants to > use our massively parallel hardware to speed up databases... ...

Re: [PERFORM] Slow count(*) again...

sgend...@ideasculptor.com (Samuel Gendler) writes: > Geez.  I wish someone would have written something quite so bold as > 'xfs is always faster than ext3' in the standard tuning docs.  I > couldn't find anything that made a strong filesystem > recommendation.  How does xfs compare to ext4?  I woun

Re: [PERFORM] large dataset with write vs read clients

cr...@postnewspapers.com.au (Craig Ringer) writes: > Hey, maybe I should try posting YouTube video answers to a few > questions for kicks, see how people react ;-) And make sure it uses the same voice as is used in the "MongoDB is web scale" video, to ensure that people interpret it correctly :-).

Re: [PERFORM] large dataset with write vs read clients

mladen.gog...@vmsinfo.com (Mladen Gogala) writes: > I have a logical problem with asynchronous commit. The "commit" > command should instruct the database to make the outcome of the > transaction permanent. The application should wait to see whether the > commit was successful or not. Asynchronous

Re: [PERFORM] read only transactions

jnelson+pg...@jamponi.net (Jon Nelson) writes: > Are there any performance implications (benefits) to executing queries > in a transaction where > SET TRANSACTION READ ONLY; > has been executed? Directly? No. Indirectly, well, a *leetle* bit... Transactions done READ ONLY do not generate actual

Re: [PERFORM] Running PostgreSQL as fast as possible no matter the consequences

gentosa...@gmail.com (A B) writes: > If you just wanted PostgreSQL to go as fast as possible WITHOUT any > care for your data (you accept 100% dataloss and datacorruption if any > error should occur), what settings should you use then? Use /dev/null. It is web scale, and there are good tutorials.

Re: [PERFORM] best db schema for time series data?

vindex+lists-pgsql-performa...@apartia.org (Louis-David Mitterrand) writes: > I have to collect lots of prices from web sites and keep track of their > changes. What is the best option? > > 1) one 'price' row per price change: > > create table price ( > id_price primary key, >

Re: [PERFORM] best db schema for time series data?

vindex+lists-pgsql-performa...@apartia.org (Louis-David Mitterrand) writes: > On Tue, Nov 16, 2010 at 11:35:24AM -0500, Chris Browne wrote: >> vindex+lists-pgsql-performa...@apartia.org (Louis-David Mitterrand) >> writes: >> > I have to collect lots of prices from web sites

Re: [PERFORM] "COPY TO stdout" statements occurrence in log files

msakre...@truviso.com (Maciek Sakrejda) writes: >> Is this normal? I'm afraid because my application doesn't run this kind of >> statement, so how can I know what is doing these commands? Maybe pg_dump? > > I think pg_dump is likely, yes, if you have that scheduled. I don't > think anything in the

Re: [PERFORM] the XID question

kevin.gritt...@wicourts.gov ("Kevin Grittner") writes: > Filip Rembia*kowski wrote: >> 2011/1/19 Charles.Hou : > >>> " select * from mybook" SQL command also increase the XID ? >> >> Yes. Single SELECT is a transaction. Hence, it needs a transaction >> ID. > > No, not in recent versions of Po

Re: [HACKERS] [PERFORM] Slow count(*) again...

mladen.gog...@vmsinfo.com (Mladen Gogala) writes: > Hints are not even that complicated to program. The SQL parser should > compile the list of hints into a table and optimizer should check > whether any of the applicable access methods exist in the table. If it > does - use it. If not, ignore it.

Re: [HACKERS] [PERFORM] Slow count(*) again...

mladen.gog...@vmsinfo.com (Mladen Gogala) writes: > I must say that this purist attitude is extremely surprising to > me. All the major DB vendors support optimizer hints, yet in the > Postgres community, they are considered bad with almost religious > fervor. > Postgres community is quite unique w

Re: [PERFORM] getting the most of out multi-core systems for repeated complex SELECT statements

gnuo...@rcn.com writes: > Time for my pet meme to wiggle out of its hole (next to Phil's, and a > day later). For PG to prosper in the future, it has to embrace the > multi-core/processor/SSD machine at the query level. It has to. And > it has to because the Big Boys already do so, to some exten

Re: [PERFORM] Why we don't want hints

robertmh...@gmail.com (Robert Haas) writes: > On Thu, Feb 10, 2011 at 11:45 AM, Kevin Grittner > wrote: >> Well, I'm comfortable digging in my heels against doing *lame* hints >> just because "it's what all the other kids are doing," which I think >> is the only thing which would have satisfied th

Re: [PERFORM] Autovacuum / full vacuum

[EMAIL PROTECTED] (Andrew Sullivan) writes: > On Tue, Jan 17, 2006 at 11:18:59AM +0100, Michael Riess wrote: >> hi, >> >> I'm curious as to why autovacuum is not designed to do full vacuum. I > > Because nothing that runs automatically should ever take an exclusive > lock on the entire database,

Re: [PERFORM] Autovacuum / full vacuum

[EMAIL PROTECTED] (Alvaro Herrera) writes: > Chris Browne wrote: >> [EMAIL PROTECTED] (Andrew Sullivan) writes: >> > On Tue, Jan 17, 2006 at 11:18:59AM +0100, Michael Riess wrote: >> >> hi, >> >> >> >> I'm curious as to why autovac

Re: [PERFORM] Autovacuum / full vacuum

[EMAIL PROTECTED] ("Mindaugas") writes: >> >> Even a database-wide vacuum does not take locks on more than one >> >> table. The table locks are acquired and released one by one, as >> >> the operation proceeds. >> >> > Has that changed recently? I have always seen "vacuumdb" or SQL >> > "VACUUM"

Re: [PERFORM] Autovacuum / full vacuum (off-topic?)

[EMAIL PROTECTED] (Michael Crozier) writes: > On Wednesday 18 January 2006 08:54 am, Chris Browne wrote: >> To the contrary, there is a whole section on what functionality to >> *ADD* to VACUUM. > > Near but not quite off the topic of VACUUM and new features... > &g

Re: [PERFORM] Investigating IO Saturation

[EMAIL PROTECTED] (Tom Lane) writes: > Brad Nicholson <[EMAIL PROTECTED]> writes: >> I'm investigating a potential IO issue. We're running 7.4 on AIX 5.1. >> During periods of high activity (reads, writes, and vacuums), we are >> seeing iostat reporting 100% disk usage. I have a feeling that

Re: [PERFORM] Default autovacuum settings too conservative

matthew@zeut.net ("Matthew T. O'Connor") writes: > 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 anything to do with the thres

Re: [PERFORM] Large Table With Only a Few Rows

"Nik" <[EMAIL PROTECTED]> writes: > I have a table that has only a few records in it at the time, and they > get deleted every few seconds and new records are inserted. Table never > has more than 5-10 records in it. > > However, I noticed a deteriorating performance in deletes and inserts > on it.

Re: [PERFORM] The trigger can be specified to fire on time condition?

[EMAIL PROTECTED] (Jamal Ghaffour) writes: > Hi All, I ' m using the postgresql datbase to stores cookies. Theses > cookies become invalid after 30 mn and have to be deleted. i have > defined a procedure that will delete all invalid cookies, but i > don't know how to call it in loop way (for exampl

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

[EMAIL PROTECTED] ("Jim C. Nasby") writes: > On Thu, Mar 23, 2006 at 09:22:34PM -0500, Christopher Browne wrote: >> 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 th

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

[EMAIL PROTECTED] ("Luke Lonergan") writes: > Christopher, > > On 3/23/06 6:22 PM, "Christopher Browne" <[EMAIL PROTECTED]> wrote: > >> Question: Does the Bizgress/MPP use threading for this concurrency? >> Or forking? >> >> If it does so via forking, that's more portable, and less dependent on >>

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

[EMAIL PROTECTED] (Michael Stone) writes: > On Fri, Mar 24, 2006 at 01:21:23PM -0500, Chris Browne wrote: >>A naive read on this is that you might start with one backend process, >>which then spawns 16 more. Each of those backends is scanning through >>one of those 16 f

Re: [PERFORM] Decide between Postgresql and Mysql (help of

[EMAIL PROTECTED] ("Craig A. James") writes: > Gorshkov wrote: >> /flame on >> if you were *that* worried about performance, you wouldn't be using >> PHP or *any* interperted language >> /flame off >> sorry - couldn't resist it :-) > > I hope this was just a joke. You should be sure to clarify -

Re: [PERFORM] Decide between Postgresql and Mysql (help of

[EMAIL PROTECTED] (Scott Marlowe) writes: > And that, nowadays, is generally the state of web development. It's > not the language you're using to write it in, it's how efficiently > you're using your database. Which properly puts my comments in their place :-). More importantly, that seems like

Re: [PERFORM] Sun Fire T2000 and PostgreSQL 8.1.3

josh@agliodbs.com (Josh Berkus) writes: > Juan, > >> When I hit >> this pgsql on this laptop with a large query I can see the load spike up >> really high on both of my virtual processors. Whatever, pgsql is doing >> it looks like both cpu's are being used indepently. > > Nope, sorry, you're bein

Re: [PERFORM] Sun Fire T2000 and PostgreSQL 8.1.3

[EMAIL PROTECTED] ("Juan Casero \(FL FLC\)") writes: > I am not sure about this. I mean I have postgresql 8.1.3 running on > my Windows XP P4 HT laptop that I use for testing my webapps. When > I hit this pgsql on this laptop with a large query I can see the > load spike up really high on both of

Re: [PERFORM] Which processor runs better for Postgresql?

[EMAIL PROTECTED] (Steve Poe) writes: > I have a client who is running Postgresql 7.4.x series database > (required to use 7.4.x). They are planning an upgrade to a new server. > They are insistent on Dell. Then they're being insistent on poor performance. If you search for "dell postgresql perfo

Re: [PERFORM] Is it possible to start two instances of postgresql?

[EMAIL PROTECTED] writes: > Is it possible to start two instances of postgresql with different port and > directory which run simultaneously? Certainly. We have one HACMP cluster which hosts 14 PostgreSQL instances across two physical boxes. (If one went down, they'd all migrate to the survivor.

Re: [PERFORM] XFS filessystem for Datawarehousing

[EMAIL PROTECTED] ("Milen Kulev") writes: > I am pretty exited whether XFS will clearly outpertform ETX3 (no > default setups for both are planned !). I am not sure whether is it > worth to include JFS in comparison too ... I did some benchmarking about 2 years ago, and found that JFS was a few p

Re: [PERFORM] XFS filessystem for Datawarehousing -2

[EMAIL PROTECTED] ("Denis Lussier") writes: > I have no personal experience with XFS, but, I've seen numerous > internal edb-postgres test results that show that of all file > systems... OCFS 2.0 seems to be quite good for PG update intensive > apps (especially on 64 bit machines). I have been cur

Re: [PERFORM] BUG #2658: Query not using index

[EMAIL PROTECTED] (Graham Davis) writes: > Adding DESC to both columns in the SORT BY did not make the query use > the multikey index. So both > > SELECT DISTINCT ON (assetid) assetid, ts > FROM asset_positions ORDER BY assetid, ts DESC; > > and > > SELECT DISTINCT ON (assetid) assetid, ts > FROM

Re: [PERFORM] BUG #2658: Query not using index

[EMAIL PROTECTED] (Graham Davis) writes: > 40 seconds is much too slow for this query to run and I'm assuming > that the use of an index will make it much faster (as seen when I > removed the GROUP BY clause). Any tips? Assumptions are dangerous things. An aggregate like this has *got to* scan t

Re: [PERFORM] Simple join optimized badly?

[EMAIL PROTECTED] (Tom Lane) writes: > Another thing we've been beat up about in the past is that loading a > pg_dump script doesn't ANALYZE the data afterward... Do I misrecall, or were there not plans (circa 7.4...) to for pg_dump to have an option to do an ANALYZE at the end? I seem to remembe

Re: [PERFORM] Simple join optimized badly?

[EMAIL PROTECTED] ("Craig A. James") writes: > Mark Kirkwood wrote: >>> The result? I can't use my function in any WHERE clause that >>> involves any other conditions or joins. Only by itself. PG will >>> occasionally decide to use my function as a filter instead of doing >>> the join or the oth

Re: [PERFORM] Optimization of this SQL sentence

[EMAIL PROTECTED] ("Merlin Moncure") writes: > On 10/17/06, Mario Weilguni <[EMAIL PROTECTED]> wrote: >> Am Dienstag, 17. Oktober 2006 11:52 schrieb Alexander Staubo: >> > Lastly, note that in PostgreSQL these length declarations are not >> > necessary: >> > >> > contacto varchar(255), >> > fuente

Re: [PERFORM] Optimization of this SQL sentence

[EMAIL PROTECTED] (Alexander Staubo) writes: > On Oct 17, 2006, at 17:29 , Mario Weilguni wrote: > >> Am Dienstag, 17. Oktober 2006 11:52 schrieb Alexander Staubo: >>> Lastly, note that in PostgreSQL these length declarations are not >>> necessary: >>> >>>contacto varchar(255), >>>fuente v

Re: [PERFORM] Why queries takes too much time to execute?

[EMAIL PROTECTED] ("Anderson Boechat Lopes") writes: >     I´m new here and i´m not sure if this is the right email to > solve my problem. This should be OK... >     Well, i have a very large database, with vary tables and very > registers. Every day, too many operations are perfomed in that DB,

Re: [PERFORM] Recommended File System Configuration

[EMAIL PROTECTED] (James Thornton) writes: > Back in 2001, there was a lengthy thread on the PG Hackers list about > PG and journaling file systems > (http://archives.postgresql.org/pgsql-hackers/2001-05/msg00017.php), > but there was no decisive conclusion regarding what FS to use. At the > time t

Re: [PERFORM] PostgreSQL caching

[EMAIL PROTECTED] (Richard Huxton) writes: > If you could "pin" data in the cache it would run quicker, but at the > cost of everything else running slower. > > Suggested steps: > 1. Read the configuration/tuning guide at: >http://www.varlena.com/varlena/GeneralBits/Tidbits/index.php > 2. Post

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

[EMAIL PROTECTED] (Neil Conway) writes: > Christopher Browne wrote: >> One of our sysadmins did all the "configuring OS stuff" part; I don't >> recall offhand if there was a need to twiddle something in order to >> get it to have great gobs of shared memory. > > FWIW, the section on configuring ker

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

[EMAIL PROTECTED] (Dan Harris) writes: > Christopher Browne wrote: > >>We have a couple of these at work; they're nice and fast, although the >>process of compiling things, well, "makes me feel a little unclean." >> > Thanks very much for your detailed reply, Christopher. Would you mind > elaborat

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

[EMAIL PROTECTED] ("Simon Riggs") writes: > Well, its fairly straightforward to auto-generate the UNION ALL view, and > important as well, since it needs to be re-specified each time a new > partition is loaded or an old one is cleared down. The main point is that > the constant placed in front of

[PERFORM] Opteron vs RHAT

[EMAIL PROTECTED] (Matt Clark) writes: >>As for "vendor support" for Opteron, that sure looks like a >>trainwreck... If you're going through IBM, then they won't want to >>respond to any issues if you're not running a "bog-standard" RHAS/RHES >>release from Red Hat. And that, on Opteron, is prepo

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

[EMAIL PROTECTED] (Pierre-Frédéric Caillaud) writes: >> posix_fadvise(2) may be a candidate. Read/Write bareers another pone, as >> well asn syncing a bunch of data in different files with a single call >> (so that the OS can determine the best write order). I can also imagine >> some interaction w

Re: [PERFORM] When to bump up statistics?

[EMAIL PROTECTED] (Dawid Kuroczko) writes: > ALTER TABLE foo ALTER COLUMN bar SET STATISTICS n; . > > I wonder what are the implications of using this statement, > I know by using, say n=100, ANALYZE will take more time, > pg_statistics will be bigger, planner will take longer time, > on the ot

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

[EMAIL PROTECTED] ("Dave Held") writes: >> -Original Message- >> From: Tom Lane [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, March 22, 2005 3:48 PM >> To: Greg Stark >> Cc: Christopher Browne; pgsql-performance@postgresql.org >> Subject: Re: [PERFORM] What about utility to calculate planner

Re: [PERFORM] Bunching "transactions"

[EMAIL PROTECTED] (Jean-David Beyer) writes: > But what is the limitation on such a thing? In this case, I am just > populating the database and there are no other users at such a time. I am > willing to lose the whole insert of a file if something goes wrong -- I > would fix whatever went wrong an

  1   2   >