Re: [PERFORM] shared_buffers > 284263 on OS X

. Thanks, ________ Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave. SE Calgary, AB T2G 0V9 http://www.clickspace.com On Nov 26, 2006, at 4:25 PM, Jim C. Nasby wrote: On Sat, Nov 18, 2006 at 08:13:

Re: [PERFORM] App very unresponsive while performing simple update

Hi Jan, That sounds like a great idea! How would you control the update to occur only every 10,000 transactions? Is there a trigger setting for that somewhere? Thanks, Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL

Re: [PERFORM] App very unresponsive while performing simple update

joins outside our category_product table tend to be very slow. We'll probably have to write a process to update the click_count from querying our product_click_history table. ________ Brendan Duddridge | CTO | 403-277-5591 x24

Re: [PERFORM] App very unresponsive while performing simple update

_id) REFERENCES media(media_id) DEFERRABLE INITIALLY DEFERRED "product_mediafordetail_fk" FOREIGN KEY (media_for_detail_id) REFERENCES media(media_id) DEFERRABLE INITIALLY DEFERRED "product_mediaforthumbnail_fk" FOREIGN KEY (media_for_thumbnail_id) REFERENCES media(med

Re: [PERFORM] App very unresponsive while performing simple update

p with this?Thanks, Brendan Duddridge | CTO | 403-277-5591 x24 |  [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave. SE Calgary, AB  T2G 0V9 http://www.clickspace.com  On May 28, 2006, at 3:37 AM, Brendan Duddridge wrote:Hi,Is Postgres supposed to be able to

[PERFORM] App very unresponsive while performing simple update

Hi,Is Postgres supposed to be able to handle concurrent requests while doing large updates?This morning I was executing the following simple update statement that would affect 220,000 rows in my product table:update product set is_hungry = 'true'  where date_modified > current_date - 10;But the app

Re: [PERFORM] Performs WAY better with enable_seqscan = off

regular join as you suggested, it's always slower. The trick is getting Postgres to use the proper index all the time. And so far the only way I can do that is by turning off sequential scans, but that's something I didn't want to do because I don't know how it would affect the perform

[PERFORM] Performs WAY better with enable_seqscan = off

Hi,I have a query that performs WAY better when I have enable_seqscan = off:explain analyze select ac.attribute_id, la.name, ac.sort_order from attribute_category ac, localized_attribute la where ac.category_id = 1001402 and la.locale_id = 101 and ac.is_browsable = 'true' and la.attribute_id =

[PERFORM] Assistance with optimizing query - same SQL, different category_id = Seq Scan

Filter: (((product_status_code)::text = 'complete'::text) AND ((product_is_active)::text = 'true'::text)) Total runtime: 7172.359 ms Notice the sequential scan of the Price table? It scanned 1,225,551 rows in the second query. Do you have any suggest

Re: [PERFORM] Slow restoration question

enough for a Postgres database? Thanks, ________ Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave. SE Calgary, AB T2G 0V9 http://www.clickspace.com On May 2, 2006, at 3:53 PM, Jim C.

Re: [PERFORM] Slow restoration question

ing as RAID 0+1. Is that the same as RAID 10 that everyone talks about? Or is it the reverse? Thanks, ________ Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave.

Re: [PERFORM] Recovery will take 10 hours

hink the real problem was the retrieval of the files. It only took maybe 1/2 a second to retrieve the file, but often took anywhere from 5 to 30 seconds to process the file. More so on the longer end of the scale. Thanks, ________

Re: [PERFORM] Recovery will take 10 hours

ktrace or kdump doesn't mention anything about stats. Thanks, ________ Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave. SE Calgary, AB T2G 0V9 http://www.cl

Re: [PERFORM] Recovery will take 10 hours

n the WAL archives don't actually archive SQL, but store only the database changes. Thanks, Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave. SE Calgary, AB T2G 0V9 http://www.clickspace.com On Apr 20, 2006, at 3:19 P

Re: [PERFORM] Recovery will take 10 hours

the WAL files from the boot drive of our database machine over the NFS to the restore machine. Thanks, ________ Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave.

Re: [PERFORM] Recovery will take 10 hours

Well our restore command is pretty basic: restore_command = 'gunzip %p' I'm not sure why that would succeed then fail. ________ Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive

Re: [PERFORM] Recovery will take 10 hours

0001018F0037.gz There didn't seem to be any issues with the NFS mount. Perhaps it briefly disconnected and came back right away. Thanks! Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactiv

Re: [PERFORM] Recovery will take 10 hours

p along until it finds one it hasn't processed yet? Thanks, ________ Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave. SE Calgary, AB T2G 0V9 http://www.clickspace.com On Apr

Re: [PERFORM] Recovery will take 10 hours

2006-04-20 16:41:46 MDT] LOG: logger shutting down The /wal_archive/0001018F0037.gz is there accessible on the NFS mount. Is there a way to continue the restore process from where it left off? Thanks, ________ Br

Re: [PERFORM] Recovery will take 10 hours

Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave. SE Calgary, AB T2G 0V9 http://www.clickspace.com On Apr 20, 2006, at 2:17 PM, Tom Lane wrote: Brendan Duddridge <[EMAIL PROTECTED]> writes: We had a database issue today that cau

[PERFORM] Recovery will take 10 hours

How can I make this go faster? Thanks, ________ Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave. SE Calgary, AB T2G 0V9 http://www

Re: [PERFORM] OT: Data structure design question: How do they count so fast?

for the current set of selected attribute values. This sounds like it could get rather complicated, so we were hoping someone might have an idea on a much simpler solution. Thanks, ________ Brendan Duddridge | CTO | 403-277-559

Re: [PERFORM] OT: Data structure design question: How do they count so fast?

an be clicked on. More work to do! Thanks, Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave. SE Calgary, AB T2G 0V9 http://www.clickspace.com On Apr 9, 2006,

[PERFORM] OT: Data structure design question: How do they count so fast?

Hi,First of all, the reason I'm posting on the PostgreSQL Performance list is we have a performance issue with one of our applications and it's related to the speed at which PostgreSQL can do counts. But it's also related to the data structure we've designed to develop our comparison shopping engin

Re: [PERFORM] Query using SeqScan instead of IndexScan

Hi Josh, Thanks. I've adjusted my effective_cache_size to 5 GB, so we'll see how that goes. I'm also doing some query and de-normalization optimizations so we'll see how those go too. ________ Brendan Duddr

Re: [PERFORM] Query using SeqScan instead of IndexScan

p with this? Thanks, ________ Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave. SE Calgary, AB T2G 0V9 http://www.clickspace.com On Apr 1, 2006, at 8:32 AM, Jim C. Nasby wrote: On Sat, Apr 01, 2006 at 11:23:37AM +1000, ch

Re: [PERFORM] Query using SeqScan instead of IndexScan

; Thanks, ________ Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave. SE Calgary, AB T2G 0V9 http://www.clickspace.com On Mar 31, 2006, at 6:23 PM, chris smith wrote: On 4/1/06, Brendan

Re: [PERFORM] Query using SeqScan instead of IndexScan

t(product_id) DEFERRABLE INITIALLY DEFERRED Not sure if that helps answer your question, but the query is pretty slow. Sometimes it takes 5 - 15 seconds depending on the category_id specified. Thanks, Brendan Duddridge | CTO | 403-277-5591

Re: [PERFORM] Query using SeqScan instead of IndexScan

http://www.clickspace.com  On Mar 29, 2006, at 8:12 PM, Brendan Duddridge wrote:Hi,I have a query that is using a sequential scan instead of an index scan. I've turned off sequential scans and it is in fact faster with the index scan.Here's my before and after.Before:ssdev=# SET enable_

[PERFORM] Query using SeqScan instead of IndexScan

Hi,I have a query that is using a sequential scan instead of an index scan. I've turned off sequential scans and it is in fact faster with the index scan.Here's my before and after.Before:ssdev=# SET enable_seqscan TO DEFAULT;ssdev=# explain analyze select cp.product_id from category_product cp, p

Re: [PERFORM] count(*) performance

Does that mean that even though autovacuum is turned on, you still should do a regular vacuum analyze periodically? Thanks, Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite

Re: [PERFORM] Really really slow query. What's a better way?

untryCode) would make any kind of difference though. Would it? Thanks! ____ Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave. SE Calgary, AB T2G 0V9 http://www.clickspace.com On Feb 24, 2006, at 12:06 AM, Christopher King

[PERFORM] Really really slow query. What's a better way?

Hi,We're executing a query that has the following plan and we're wondering given the size of the data set, what's a better way to write the query? It's been running since 2pm 2 days ago.explain DELETE FROM cds.cds_mspecxx WHERE ProdID not in (SELECT stage.ProdID FROM cds_stage.cds_Catalog stage whe

Re: [PERFORM] LIKE query on indexes

Hi,Can this technique work with case insensitive ILIKE?It didn't seem to use the index when I used ILIKE instead of LIKE.Thanks, Brendan Duddridge | CTO | 403-277-5591 x24 |  [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L1

Re: [PERFORM] Hardware/OS recommendations for large databases (

hanks, Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave. SE Calgary, AB T2G 0V9 http://www.clickspace.com On Nov 27, 2005, at 8:09 PM, David Lang wrote: On Mon, 28 Nov

Re: [PERFORM] Hardware/OS recommendations for large databases (

Forgive my ignorance, but what is MPP? Is that part of Bizgres? Is it possible to upgrade from Postgres 8.1 to Bizgres? Thanks, Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc