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] 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: [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: [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: [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: [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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] Master/Slave, DB separation or just spend $$$?

kelv...@gmail.com (Kelvin Quee) writes: > I will go look at Slony now. It's worth looking at, but it is not always to be assumed that replication will necessarily improve scalability of applications; it's not a "magic wand" to wave such that "presto, it's all faster!" Replication is helpful from

Re: [PERFORM] superlative missuse

cl...@uah.es (Angel Alvarez) writes: > more optimal plan... > morreoptimal configuration... > > we suffer a 'more optimal' superlative missuse > > there is not so 'more optimal' thing but a simple 'better' thing. > > im not native english speaker but i think it still applies. If I wanted to be p

Re: [PERFORM] I have a fusion IO drive available for testing

craig_ja...@emolecules.com (Craig James) writes: > Dave Cramer wrote: >> So I tried writing directly to the device, gets around 250MB/s, >> reads at around 500MB/s >> >> The client is using redhat so xfs is not an option. > > I'm using Red Hat and XFS, and have been for years. Why is XFS not an opt

Re: [PERFORM] scheduling autovacuum at lean hours only.

mallah.raj...@gmail.com (Rajesh Kumar Mallah) writes: > why is it not a good idea to give end users control over when they > want to run it ? It's not a particularly good idea to give end users things that they are likely then to *immediately* use to shoot themselves in the foot. Turning off vacu

Re: [PERFORM] PG performance in high volume environment (many INSERTs and lots of aggregation reporting)

phoenix.ki...@gmail.com (Phoenix Kiula) writes: > [Ppsted similar note to PG General but I suppose it's more appropriate > in this list. Apologies for cross-posting.] > > Hi. Further to my bafflement with the "count(*)" queries as described > in this thread: > > http://archives.postgresql.org/pgsql

Re: [PERFORM] Intel's X25-M SSD

[EMAIL PROTECTED] ("Merlin Moncure") writes: > I think the SSD manufacturers made a tactical error chasing the > notebook market when they should have been chasing the server > market... That's a very good point; I agree totally! -- output = reverse("moc.enworbbc" "@" "enworbbc") http://www3.symp

Re: [PERFORM] [QUESTION]Concurrent Access

[EMAIL PROTECTED] ("Leví Teodoro da Silva") writes: > Hi guys, How are you ? > I am from Brazil and i work for a little company and it company is working is > medium-big project and we want to use PostGree like the DataBase > system, but i got some questions. > I want to know if the PostGree has l

Re: [PERFORM] Federated Postgresql architecture ?

[EMAIL PROTECTED] (Josh Berkus) writes: > Jonah, > >> Hmm, I didn't think the Skype tools could really provide federated >> database functionality without a good amount of custom work. Or, am I >> mistaken? > > Sure, what do you think pl/proxy is for? Ah, but the thing is, it changes the model fr

[PERFORM] OVERLAPS is slow

I'm doing some analysis on temporal usages, and was hoping to make use of OVERLAPS, but it does not appear that it makes use of indices. Couching this in an example... I created a table, t1, thus: metadata=# \d t1 Table "public.t1" Column | Type

Re: [PERFORM] Replication Syatem

[EMAIL PROTECTED] ("Gauri Kanekar") writes: > Basically we have some background process which updates "table1" and > we don't want the application to make any changes to "table1" while > vacuum. Vacuum requires exclusive lock on "table1" and if any of > the background or application is ON vacuum d

Re: [PERFORM] Replication Syatem

[EMAIL PROTECTED] ("Gauri Kanekar") writes: > We have a table "table1" which get insert and updates daily in high > numbers, bcoz of which its size is increasing and we have to vacuum > it every alternate day. Vacuuming "table1" take almost 30min and > during that time the site is down. We need to

Re: [PERFORM] Where do a novice do to make it run faster?

[EMAIL PROTECTED] ("A B") writes: > So, it is time to improve performance, it is running to slow. > AFAIK (as a novice) there are a few general areas: > > 1) hardware > 2) rewriting my queries and table structures > 3) using more predefined queries > 4) tweek parameters in the db conf files > > Of

Re: [PERFORM] Message queue table..

[EMAIL PROTECTED] (Jesper Krogh) writes: > I have this "message queue" table.. currently with 8m+ > records. Picking the top priority messages seem to take quite > long.. it is just a matter of searching the index.. (just as explain > analyze tells me it does). > > Can anyone digest further optimiz

Re: [PERFORM] Background writer underemphasized ...

[EMAIL PROTECTED] (Marinos Yannikos) writes: > This helped with our configuration: > bgwriter_delay = 1ms # 10-1ms between rounds > bgwriter_lru_maxpages = 1000 # 0-1000 max buffers written/round FYI, I'd be inclined to reduce both of those numbers, as it should reduce the vari

Re: [PERFORM] Oddly slow queries

[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 >>> even if they take ~2-3 sec under "normal" conditions, there are no >>> sequencial scans done in those queries. There are not many users >>> co

Re: [PERFORM] postgresql is slow with larger table even it is in RAM

[EMAIL PROTECTED] ("sathiya psql") writes: > On Tue, Mar 25, 2008 at 2:09 PM, jose > javier parra sanchez <[EMAIL PROTECTED]> wrote: > > > It's been said zillions of > times on the maillist. Using a select >

Re: [PERFORM] which is more important? freq of checkpoints or the duration of them?

[EMAIL PROTECTED] (Douglas J Hunley) writes: > Subject about says it all. Should I be more concerned about checkpoints > happening 'frequently' or lasting 'longer'? In other words, is it ok to > checkpoint say, every 5 minutes, if it only last a second or three or better > to have checkpoints ev

Re: [PERFORM] Making the most of memory?

[EMAIL PROTECTED] (Florian Weimer) writes: >> So, that web site seems to list products starting at about 32GB in a >> separate rack-mounted box with redundant everything. I'd be more >> interested in just putting the WAL on an SSD device, so 500MB or 1GB >> would be quite sufficient. Can anyone poi

Re: [PERFORM] Making the most of memory?

[EMAIL PROTECTED] ("Scott Marlowe") writes: > On Jan 23, 2008 1:57 PM, Guy Rouillier <[EMAIL PROTECTED]> wrote: >> Scott Marlowe wrote: >> > I assume you're talking about solid state drives? They have their >> > uses, but for most use cases, having plenty of RAM in your server will >> > be a bette

Re: [PERFORM] viewing source code

[EMAIL PROTECTED] ("Roberts, Jon") writes: > I think it is foolish to not make PostgreSQL as feature rich when it > comes to security as the competition because you are idealistic when > it comes to the concept of source code. PostgreSQL is better in > many ways to MS SQL Server and equal to many

Re: [PERFORM] Need to run CLUSTER to keep performance

[EMAIL PROTECTED] (Rafael Martinez) writes: > Heikki Linnakangas wrote: >> On a small table like that you could run VACUUM every few minutes >> without much impact on performance. That should keep the table size in >> check. >> > > Ok, we run VACUUM ANALYZE only one time a day, every night. But we

Re: [PERFORM] Bunching "transactions"

[EMAIL PROTECTED] (Jean-David Beyer) writes: > Chris Browne wrote: >> [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 &g

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

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] 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] 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] 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] 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] 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] 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] 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] 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] 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] [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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] ("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] 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] 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] 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] 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] 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] 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

[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] (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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] (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

  1   2   >