Re: [PERFORM] DELETE performance problem

You may want to consider using partitioning. That way you can drop the appropriate partition and never have the overhead of a delete. Jerry Champlin|Absolute Performance Inc.|Mobile: 303-588-2547 -Original Message- From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance

Re: [PERFORM] Number of tables

I think this requirement can be lumped into the category of right hammer, right nail instead of the one hammer, all nails category. There are many memory only or disk backed memory based key value stores which meet your requirements like Reddis and memcached. -Jerry Jerry Champlin

Re: [PERFORM] load / stress testing

-30K. I'd be happy to have a conversation if you are serious about solving this problem. -Jerry Jerry Champlin Absolute Performance Inc. O: (303) 443-7000 x501 C: (303) 588-2547 jchamp...@absolute-performance.com Chris wrote: Hi, Everyone says load test using your app - out of interest

Re: [PERFORM] Hosted servers with good DB disk performance?

high bandwidth - historically they have been very successful in the MPOG world. If you are interested, I can put you in touch with real people who can help you at all three organizations. Jerry Champlin|Absolute Performance Inc. -Original Message- From: pgsql-performance-ow

Re: [PERFORM] Raid 10 chunksize

. You could also look at using something like Tokyo Cabinet as a short term front end data store. Without understanding the application architecture, I can't offer much in way of a specific suggestion. -Jerry Jerry Champlin Absolute Performance Inc. Mark Kirkwood wrote: Scott Marlowe wrote

Re: [PERFORM] Deleting millions of rows

of database platform. -Jerry Jerry Champlin|Absolute Performance Inc.|Mobile: 303-588-2547 -Original Message- From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Brian Cox Sent: Monday, February 02, 2009 11:18 AM To: pgsql-performance

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

Another approach we used successfully for a similar problem -- (we had lots of free high memory but were running out of low memory; oom killer wiped out MQ a couple times and postmaster a couple times) -- was to change the settings for how aggressively the virtual memory system protected low

[PERFORM] Is there a way to SubPartition?

Is there a way to use multi-level inheritance to achieve sub partitioning that the query optimizer will recognize? With our current application design, we would need a partition for every other day for 18 months which will not perform well. The reason we need so many partitions is that we

Re: [PERFORM] Is there a way to SubPartition?

? Buffers written by the bgwriter vs checkpoint is 6 to 1. Buffers written by clients vs buffers by checkpoint is 1 to 6. Is there anything obvious here? -Jerry -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 27, 2008 8:02 AM To: Jerry Champlin Cc: pgsql

[PERFORM] Autovacuum does not stay turned off

We are attempting to turn off autovacuum but it keeps coming back. We can't afford the performance hit from vacuum while end users are accessing our system. Postgresql Version: 8.3.3 OS: Linux 2.6.18-53.el5PAE #1 SMP Running PostgreSQL setting: sspg=# show autovacuum; autovacuum

Re: [PERFORM] Autovacuum does not stay turned off

lubaczewski wrote: On Tue, Aug 26, 2008 at 09:27:48AM -0600, Jerry Champlin wrote: Does anyone know what will cause this bahavior for autovacuum? http://www.postgresql.org/docs/current/interactive/runtime-config-autovacuum.html - autovacuum_freeze_max_age depesz Andrew Sullivan

Re: [PERFORM] Autovacuum does not stay turned off

wrote: On Tue, Aug 26, 2008 at 10:45:31AM -0600, Jerry Champlin wrote: This makes sense. What queries can I run to see how close to the limit we are? We need to determine if we should stop the process which updates and inserts into this table until after the critical time this afternoon when