Re: [PERFORM] Postgres using more memory than it should

too much memory to allocate for work_mem. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 IMPORTANT: This message contains confidential information

Re: [PERFORM] select on 22 GB table causes An I/O error occured while sending to the backend. exception

In response to Greg Smith [EMAIL PROTECTED]: On Thu, 28 Aug 2008, Bill Moran wrote: In linux, it's possible to tell the OOM killer never to consider certain processes for the axe, using /proc magic. See this page: http://linux-mm.org/OOM_Killer Perhaps this should

Re: [PERFORM] select on 22 GB table causes An I/O error occured while sending to the backend. exception

for the axe, using /proc magic. See this page: http://linux-mm.org/OOM_Killer Perhaps this should be in the PostgreSQL docs somewhere? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent via pgsql-performance

Re: [PERFORM] select on 22 GB table causes An I/O error occured while sending to the backend. exception

you months ahead of time when you're going to need to scale up to bigger hardware. On a side note, what version of PG are you using? If it was in a previous email, I missed it. Hope this helps. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ -- Sent via

Re: [PERFORM] Big delete on big table... now what?

probably be able to maintain performance and table bloat at a reasonable level with normal vacuum. -- Bill Moran Collaborative Fusion Inc. [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription

Re: [PERFORM] Using PK value as a String

) This allows you to still use int4 or int8. UUID is designed to be a universal solution. But universal solutions are frequently less efficient than custom-tailored solutions. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422

Re: [PERFORM] Using PK value as a String

(compare the id of the newest user to the id a week ago). This is information which is in some cases critical. So you're accidentally storing critical information in magic values instead of storing it explicitly? Good luck with that. -- Bill Moran Collaborative Fusion Inc. http

Re: [PERFORM] Using PK value as a String

In response to Moritz Onken [EMAIL PROTECTED]: Am 12.08.2008 um 17:04 schrieb Bill Moran: In response to Moritz Onken [EMAIL PROTECTED]: We chose UUID as PK because there is still some information in an integer key. You can see if a user has registered before someone else (user1.id

Re: [PERFORM] Using PK value as a String

In response to Steve Atkins [EMAIL PROTECTED]: On Aug 12, 2008, at 8:21 AM, Bill Moran wrote: In response to Moritz Onken [EMAIL PROTECTED]: Am 12.08.2008 um 17:04 schrieb Bill Moran: In response to Moritz Onken [EMAIL PROTECTED]: We chose UUID as PK because there is still

Re: [PERFORM] Difference between Explain analyze and \timing

on the client side. -- Bill Moran Collaborative Fusion Inc. [EMAIL PROTECTED] Phone: 412-422-3463x4023 IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader

Re: [PERFORM] how big shmmax is good for Postgres...

, which will be 4G if this machine only runs PostgreSQL, but could be less if it runs other things like a web server. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent via pgsql-performance mailing list

Re: [PERFORM] max fsm pages question

FULL. If you don't handle this, that table will continue to grow in size on the disk, taking up space unnecessarily and probably negatively impacting performance. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023

Re: [PERFORM] How much work_mem to configure...

. It doesn't change anything that Scott said, it simply gives you another way to monitor what's happening and thus have better information to tune by. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent via pgsql

Re: [PERFORM] Author Wanted

let me know. Please let me know, I'd be very happy if you could contribute... (Don't worry about language!) :-) Can you provide detailed information on submission guidelines as well as pay rates? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL

Re: [PERFORM] Problem with 11 M records table

not know how to do it. Please help me! Thank you, Danny -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance -- Bill Moran Collaborative Fusion Inc. http

Re: [PERFORM] Background writer underemphasized ...

. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Background writer underemphasized ...

In response to Greg Smith [EMAIL PROTECTED]: On Wed, 16 Apr 2008, Bill Moran wrote: bgwriter_delay = 1ms # 10-1ms between rounds bgwriter_lru_maxpages = 1000 # 0-1000 max buffers written/round Have you watched closely under load to ensure that you're not seeing

Re: [PERFORM] db size

compression than the running database. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http

Re: [PERFORM] large tables and simple = constant queries using indexes

are in the buffer in real time. If you're having trouble, it can (potentially) be a helpful tool. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent via pgsql-performance mailing list (pgsql-performance

Re: [PERFORM] large tables and simple = constant queries using indexes

ON gene_prediction_view USING btree (gene_ref); -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance -- Bill Moran Collaborative Fusion Inc. http

Re: [PERFORM] Looking for bottleneck during load test

-performance -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 IMPORTANT: This message contains confidential information and is intended only

Re: [PERFORM] Looking for bottleneck during load test

In response to Greg Smith [EMAIL PROTECTED]: On Mon, 7 Apr 2008, Bill Moran wrote: You know, with all the performance problems people have been bringing up with regard to SANs, I'm putting SAN in the same category as RAID-5 ... Not really fair, because unlike RAID5 it's at least

Re: [PERFORM] Slow query or just Bad hardware?

with 32GB of ram and Equalogic iSCSI SAN attached. Jesper -- Jesper Krogh -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance -- Bill Moran Collaborative Fusion Inc

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

filesystem did you format the RAM disk with? Why are you doing this? If you have enough RAM to store the table, why not just allocate it to shared buffers? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent

Re: [PERFORM] what is the maximum number of rows in a table in postgresql 8.1

rows. I don't see any performance issue here. What were your expectations? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make

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

conversation? What are you hoping to accomplish? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription

Re: [PERFORM] PG writes a lot to the disk

, then something else is going on than what Tom suggested. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription

Re: [PERFORM] PG writes a lot to the disk

in his SELECTs that are modifying table data, or triggers that do it ON SELECT or something similar. Of course, without any details, this is purely speculation. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent

Re: [PERFORM] question on TRUNCATE vs VACUUM FULL

: http://www.postgresql.org/mailpref/pgsql-performance -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 IMPORTANT: This message contains confidential

Re: [PERFORM] PG writes a lot to the disk

a value this high will actually be used. max_stack_depth = 7MB default_statistics_target = 100 effective_cache_size = 20GB -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023

Re: [PERFORM] question on TRUNCATE vs VACUUM FULL

to reproduce the behaviour on systems where they can investigate it. Once you have that, use the bug reporting form on the web site to report it as a bug. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent via

Re: [PERFORM] count * performance issue

, but shouldn't something like this allow us to get a (fast) accurate count ? SELECT COUNT(*) from table WHERE indexed_field IS NULL + SELECT COUNT(*) from table WHERE indexed_field IS NOT NULL For certain, qualified definitions of fast, sure. -- Bill Moran Collaborative Fusion Inc. http

Re: [PERFORM] Toast space grows

of this table so you can easily watch to see if your config tweaks are getting the job done or not. And remember that _some_ bloat is expected and normal for operation. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422

Re: [PERFORM] count * performance issue

? -- Bill Moran -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-performance

Re: [PERFORM] PostgreSQL performance on a virtual host

?domain=postgresql.orgextra=pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-performance -- Bill Moran Collaborative Fusion Inc. http

Re: [PERFORM] postgresql performance

in a production system. Note that if you need a fast count of the number of rows in a large table, there are known workarounds to get it. Such as creating triggers that update a count column, or using explain to get a quick estimate of the number of rows (if that's acceptable). -- Bill Moran

Re: [PERFORM] Performance tuning on FreeBSD

advice applies to FreeBSD as well as to most other OS. -- Bill Moran Collaborative Fusion Inc. [EMAIL PROTECTED] Phone: 412-422-3463x4023 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your Subscription: http://mail.postgresql.org/mj/mj_wwwusr

Re: [PERFORM] questions about CLUSTER

frequently used to fetch ranges of data. Whether that index is compound or not isn't likely to factor in. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast

Re: [PERFORM] questions about CLUSTER

years back, it's embarrassing ... -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ

Re: [PERFORM] Example web access to Postgres DB

you're going to have to be more specific. I don't know what technology uses WAR files, and based on the tepid response, it doesn't seem like anyone else on the list does either. What program are you using that uses the WAR files? -- Bill Moran Collaborative Fusion Inc. [EMAIL PROTECTED] Phone

Re: [PERFORM] Making the most of memory?

, then turn it back off. Maybe once a week or so. Hope this helps. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast)--- TIP 5: don't forget

Re: [PERFORM] With 4 disks should I go for RAID 5 or RAID 10

In response to Mark Mielke [EMAIL PROTECTED]: Bill Moran wrote: What do you mean heard of? Which raid system do you know of that reads all drives for RAID 1? I'm fairly sure that FreeBSD's GEOM does. Of course, it couldn't be doing consistency checking at that point

Re: [PERFORM] With 4 disks should I go for RAID 5 or RAID 10

In response to Mark Mielke [EMAIL PROTECTED]: Bill Moran wrote: In response to Mark Mielke [EMAIL PROTECTED]: Bill Moran wrote: I'm fairly sure that FreeBSD's GEOM does. Of course, it couldn't be doing consistency checking at that point. According

Re: [PERFORM] With 4 disks should I go for RAID 5 or RAID 10

RAID 10. I snipped the rest of your message because none of it matters. Never use RAID 5 on a database system. Ever. There is absolutely NO reason to every put yourself through that much suffering. If you hate yourself that much just commit suicide, it's less drastic. -- Bill Moran

Re: [PERFORM] With 4 disks should I go for RAID 5 or RAID 10

trying to fix your mistake. It's called tripping over a dime to pick up a nickel. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast)--- TIP 1

Re: [PERFORM] With 4 disks should I go for RAID 5 or RAID 10

of that reads all drives for RAID 1? I'm fairly sure that FreeBSD's GEOM does. Of course, it couldn't be doing consistency checking at that point. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023

Re: [PERFORM] With 4 disks should I go for RAID 5 or RAID 10

In response to Mark Mielke [EMAIL PROTECTED]: Bill Moran wrote: In order to recalculate the parity, it has to have data from all disks. Thus, if you have 4 disks, it has to read 2 (the unknown data blocks included in the parity calculation) then write 2 (the new data block and the new

Re: [PERFORM] viewing source code

added to functions so administrators can control who can view the function body. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast)--- TIP 1

Re: [PERFORM] viewing source code

functions? Um ... why did you snip my second paragraph where I said exactly this? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast)--- TIP 5: don't

Re: [PERFORM] viewing source code

In response to Joshua D. Drake [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 14 Dec 2007 11:18:49 -0500 Bill Moran [EMAIL PROTECTED] wrote: That is like saying anyone that has rights to call a web service should be able to see the source code

Re: [PERFORM] Evaluation of PG performance vs MSDE/MSSQL 2000 (not 2005)

found problematic queries. Another piece of broadly useful advice is to install the pgbuffercache addon and monitor shared_buffer usage to see if you've got enough. Also useful is monitoring the various statistics in the pg_stat_database table. -- Bill Moran Collaborative Fusion Inc. http

Re: [PERFORM] Appending LIMIT to query drastically decreases performance

EXPLAIN ANALYZE output for the two queries. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 IMPORTANT: This message contains confidential information

Re: [PERFORM] TB-sized databases

a sequential scan of this table. It's silly. I would rather the query failed than have to wait for a sequential scan of the entire table. Yes, that would be really useful, if you have huge tables in your database. Is there something wrong with: set enable_seqscan = off ? -- Bill Moran

Re: [PERFORM] TB-sized databases

In response to Gregory Stark [EMAIL PROTECTED]: Bill Moran [EMAIL PROTECTED] writes: In response to Matthew [EMAIL PROTECTED]: On Tue, 27 Nov 2007, Pablo Alcaraz wrote: it would be nice to do something with selects so we can recover a rowset on huge tables using a criteria

Re: [PERFORM] Query only slow on first run

this situation are probably 90% or better. Other things that could cause this problem are poor schema design, and unreasonable expectations. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end

Re: [PERFORM] tuning for TPC-C benchmark

= '' # list of custom variable class names -- Bill Moran Collaborative Fusion Inc. [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] autovacuum: recommended?

is not that the distro is bad because it hasn't moved from 8.1 - 8.2. The comment is that it's bad because it hasn't updated a major branch with the latest bug fixes. i.e. it hasn't moved from 8.1.4 to 8.1.5. If this is indeed the case, I agree that such a distro isn't worth using. -- Bill Moran

Re: [PERFORM] Clustered/covering indexes (or lack thereof :-)

( topic_id int, post_ids int[], post_texts text[] ) Now add a trigger to your original table that updates materialized_topics any time the first table is altered. Thus you always have fast lookups. Of course, this may be non-optimal if that table sees a lot of updates. -- Bill Moran Collaborative

Re: [PERFORM] PostgreSQL vs MySQL, and FreeBSD

testing very low-level aspects of performance. Actually, what it's really showing is parallelism, and I've always expected PostgreSQL to come out on top in that arena. -- Bill Moran Potential Technologies http://www.potentialtech.com ---(end of broadcast

Re: [PERFORM] work_mem and shared_buffers

. -- Bill Moran Potential Technologies http://www.potentialtech.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate

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

minutes. Vacuuming once a day is usually only enough if you have very minimal updates. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast)--- TIP 6

Re: [PERFORM] 12 hour table vacuums

of broadcast)--- TIP 5: don't forget to increase your free space map settings -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023

Re: [PERFORM] 12 hour table vacuums

In response to Ron St-Pierre [EMAIL PROTECTED]: Bill Moran wrote: In response to Ron St-Pierre [EMAIL PROTECTED]: We vacuum only a few of our tables nightly, this one is the last one because it takes longer to run. I'll probably re-index it soon, but I would appreciate any

Re: [PERFORM] Postgres running Very slowly

. CPU 0.02s/0.01u sec elapsed 0.02 sec. INFO: free space map: 167 relations, 1412 pages stored; 3440 total pages needed DETAIL: Allocated FSM size: 1000 relations + 2 pages = 178 kB shared memory. VACUUM This doesn't look problematic, so I doubt your vacuum policy is to blame. -- Bill

Re: [PERFORM] quickly getting the top N rows

the table, thus PG has awful statistics and doesn't know how to pick a good plan. 2) You have so few rows in the table that a seq scan is actually faster than an index scan, which is why PG uses it instead. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran

Re: [PERFORM] select count(*) performance (vacuum did not help)

large delete operations as well. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project

Re: [PERFORM] Upgraded from 7.4 to 8.1.4 QUERIES NOW SLOW!!!

-- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 IMPORTANT: This message contains confidential information and is intended only for the individual named

Re: [PERFORM] Low CPU Usage

case). But the weird thing is running the query in the new server the are many disk access and cpu usage. And with other applications in the same server are a lot of disks access. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED

Re: [PERFORM] Low CPU Usage

! Not network, no. But the results of your explains seem to show that the query is executing much faster on the new system than the old, so the problem still becomes, what is happening after the query completes that is so slow? It's just that networking is ruled out. -- Bill Moran Collaborative Fusion

Re: R: [PERFORM] R: DELETE queries slow down

on the information you've given and the responses you've made, I think you're as likely to roll a 1d6 and get the right solution as anything else. Good luck. -Messaggio originale- Da: Bill Moran [mailto:[EMAIL PROTECTED] Inviato: martedì 18 settembre 2007 18.19 A: Galantucci Giovanni Cc

Re: [PERFORM] R: DELETE queries slow down

for the query to finish using the page it's using. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner

Re: [PERFORM] Vacum Analyze problem

in advance To add to Mikko's comments: Periodic vacuuming and analyzing is a mandatory part of running a PostgreSQL database server. You'll probably be best served to configure the autovacuum daemon to handle this for you. See the postgresql.conf config file. -- Bill Moran Collaborative Fusion Inc

Re: [PERFORM] About autovacuum

about its activities. There were discussions on other lists about improving autovacuum's log messages, I'm pretty sure it will log more helpful information in 8.3. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023

Re: [PERFORM] Transaction Log

=electronicsqid=1188418613sr=8-1 http://techreport.com/articles.x/9312/1 Up to 4G, but you have to add the price of the RAM on to the price of the card. In the case of WAL logs, you could probably get away with a lot less space than many other usages, so they might be very practical. -- Bill Moran

Re: [PERFORM] Postgres performance problem

our extensive FAQ? http://www.postgresql.org/docs/faq -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 IMPORTANT

Re: [PERFORM] Performance issue

. The explain analyze output is going to be key to working this out -- unless it's something like your postgresql.conf isn't properly tuned. I vacuum and reindex the database daily. I'd prefer not to have to rewrite the code, so any suggestions would be very welcome. -- Bill Moran Collaborative

Re: [PERFORM] significant vacuum issues - looking for suggestions

checked our extensive FAQ? http://www.postgresql.org/docs/faq -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023

Re: [PERFORM] significant vacuum issues - looking for suggestions

afford any downtime, you may be able to use Slony to do your upgrade. However, slony adds overhead, and if this system is tapped out already, it may not tolerate the additional overhead. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED

Re: [PERFORM] deadlock_timeout parameter in Postgresql.cof

? http://www.postgresql.org/docs/8.2/static/runtime-config-locks.html -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast)--- TIP 9: In versions below

Re: [PERFORM] When/if to Reindex

In response to Decibel! [EMAIL PROTECTED]: On Wed, Aug 08, 2007 at 03:27:57PM -0400, Bill Moran wrote: I've had similar experience. One thing you didn't mention that I've noticed is that VACUUM FULL often bloats indexes. I've made it SOP that after application upgrades (which usually

Re: [PERFORM] When/if to Reindex

be recommended if you didn't expect the index contents to change? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast)--- TIP 6: explain analyze is your

Re: [PERFORM] disk filling up

policy to get rid of old data, or increase the amount of storage to accommodate the data you want to keep. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast

Re: [PERFORM] Simple select hangs while CPU close to 100%

postgresql.conf settings. What other activity is occurring during this long count()? Can you give us a shot of the iostat output and/or top during this phenomenon? Jozsef -Original Message- From: Bill Moran [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 25, 2007 1:12 PM To: Jozsef

Re: [PERFORM] Simple select hangs while CPU close to 100%

://archives.postgresql.org -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 IMPORTANT: This message contains confidential information and is intended

Re: [PERFORM] Simple select hangs while CPU close to 100%

-- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 IMPORTANT: This message contains confidential information and is intended only for the individual

Re: [PERFORM] Is it possible to know where is the deadlock

-locks.html If none of those are the case, then please describe the actual problem you are having. HTH. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast

Re: [PERFORM] Query is taking 5 HOURS to Complete on 8.1 version

+ max_prepared_transactions) # lock table slots. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings

Re: [PERFORM] Database-wide VACUUM ANALYZE

. Hmmm... I wonder why this would just start now, three days ago. Everything seemed to be normal for the last two weeks. Someone alter /etc/periodic.conf? Perhaps it's been running all along but you never noticed it before now? -- Bill Moran Collaborative Fusion Inc. http

Re: [PERFORM] cached entities

at the pg_buffercache contrib module. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast)--- TIP 6: explain analyze is your friend

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

! -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 IMPORTANT: This message contains confidential information and is intended only for the individual

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

an appropriate autovaccum schedule would not apply to your scenario. I'm not saying it does, only that your response does not indicate that it doesn't, and thus I'm concerned that you're writing autovacuum off without proper research. -- Bill Moran Collaborative Fusion Inc. http

Re: [PERFORM] VACUUM vs auto-vacuum daemon

switch to once a week, then probably settle on once a month to ensure nothing ever gets out of hand. Put it in a cron job and have the output mailed. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023

Re: [PERFORM] How much memory PostgreSQL is going to use?

for processing individual queries. See work_mem. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please

Re: [PERFORM] VACUUM vs auto-vacuum daemon

manual vacuum and autovacuum together, and you'll be able to gather _some_ information about how well autovacuum is keeping up. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end

Re: [PERFORM] Please help me understand these numbers

is right, you'll probably see improved performance by allocating more shared memory to PostgreSQL, thus avoiding having to move data from one area in memory to another before it can be used. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED

Re: [PERFORM] Please help me understand these numbers

In response to Chris Hoover [EMAIL PROTECTED]: On 6/8/07, Bill Moran [EMAIL PROTECTED] wrote: In response to Chris Hoover [EMAIL PROTECTED]: I need some help. I have started taking snapshots of performance of my databases with concerns to io. I created a view on each cluster

Re: [PERFORM] PostgreSQL not fully utilizing system resources?

the database is. Provide the output of vacuum verbose. -- Bill Moran Collaborative Fusion Inc. [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose

Re: [PERFORM] DB cluster sharing between 32 and 64 bit software versions

work, unfortunately. The on-disk representation of the data is different between ia32 and amd64. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast

Re: [PERFORM] PITR performance costs

Dave Cramer [EMAIL PROTECTED] wrote: Since PITR has to enable archiving does this not increase the amount of disk I/O required ? It does increase the required amount of I/O. -- Bill Moran http://www.potentialtech.com ---(end of broadcast

Re: [PERFORM] pg_stats how-to?

-- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ [EMAIL PROTECTED] Phone: 412-422-3463x4023 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings

  1   2   >