Re: [PERFORM] TCP network cost

On Feb 17, 2009, at 1:04 PM, Ross J. Reedstrom wrote: On Tue, Feb 17, 2009 at 12:20:02AM -0700, Rusty Conover wrote: Try running tests with ttcp to eliminate any PostgreSQL overhead and find out the real bandwidth between the two machines. If its results are also slow, you know the problem

Re: [PERFORM] TCP network cost

, you know the problem is TCP related and not PostgreSQL related. Cheers, Rusty -- Rusty Conover rcono...@infogears.com InfoGears Inc / GearBuyer.com / FootwearBuyer.com http://www.infogears.com http://www.gearbuyer.com http://www.footwearbuyer.com

Re: [PERFORM] GIST versus GIN indexes for intarrays

On Feb 12, 2009, at 2:29 PM, Tom Lane wrote: Rusty Conover writes: The gist__int_ops is the default operator class for integer[] arrays, as shown at: http://www.postgresql.org/docs/current/static/intarray.html Ah, so you have contrib/intarray installed. [ pokes at it... ] Seems like what

Re: [PERFORM] GIST versus GIN indexes for intarrays

On Feb 12, 2009, at 1:54 PM, Tom Lane wrote: Rusty Conover writes: Since 100% of my queries are for retrieval, I should use GIN but it never appears to be used unlike how GIST indexes are: You haven't shown us either the table or the index declaration, so it's a bit tough to

[PERFORM] GIST versus GIN indexes for intarrays

Index Cond: (fast_colors @> '{0}'::integer[]) (5 rows) Any insight is greatly appreciated. Could this be a regression from 8.3.5 and 8.3.6? Thanks, Rusty -- Rusty Conover rcono...@infogears.com InfoGears Inc / GearBuyer.com / FootwearBuyer.com http://www.infogears.com http://www.gearbuyer.com http://www.footwearbuyer.com

Re: [PERFORM] Perl/DBI vs Native

serland profile tool should help you debug what's going on here. Cheers, Rusty -- Rusty Conover InfoGears Inc. http://www.infogears.com - http://www.gearbuyer.com - http://www.footwearbuyer.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make change

Re: [PERFORM] Subquery WHERE IN or WHERE EXISTS faster?

ng executed. If you're looking for generic caching, I'd suggest memcached may be able to fill your needs. Cheers, Rusty -- Rusty Conover InfoGears Inc. http://www.infogears.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make

Re: [PERFORM] Out of memory for Select query.

r platform. Also look at "ulimit -a" as the postgres user to make sure you aren't running into any administrative limits. Cheers, Rusty -- Rusty Conover InfoGears Inc. http://www.infogears.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make cha

Re: [PERFORM] Subquery WHERE IN or WHERE EXISTS faster?

hat it doesn't pull all of the tuples before it starts processing matches. So in summary both are good to know how to use, but choosing which one to use can really depend on your data set and resources. Cheers, Rusty -- Rusty Conover InfoGears Inc. http://www.infogears.com -- Sent via p

Re: [PERFORM] Postgresql update op is very very slow

u properly increased your number of checkpoint segments? Any warnings in in your log file about excessive checkpointing? Cheers, Rusty -- Rusty Conover InfoGears Inc. http://www.infogears.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes t

Re: [PERFORM] Regexps - never completing join.

On May 16, 2008, at 2:35 PM, Scott Marlowe wrote: On Wed, May 14, 2008 at 9:33 AM, Rusty Conover <[EMAIL PROTECTED]> wrote: Returning to this problem this morning, I made some more insight. One way I did find that worked to control the loop (but doesn't yield the same results

Re: [PERFORM] Regexps - never completing join.

loops=1) Total runtime: 149067.764 ms (6 rows) Thanks, Rusty -- Rusty Conover InfoGears Inc. http://www.infogears.com -- 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] Regexps - never completing join.

On May 13, 2008, at 11:45 PM, Rusty Conover wrote: Hi Guys, I'm using postgresql 8.3.1 and I'm seeing weird behavior between what I expect and what's happening when the query is executed I'm trying to match a table that contains regexps against another table that

[PERFORM] Regexps - never completing join.

lect count(*) from wc_rule; count --- 701 (1 row) I have exports of the tables up at so you can try it if you'd like. http://rusty.devel.infogears.com/regexp-tables.tar.bz2 Any insight is greatly appreciated, even if it's just showing me how I made a mistake in the query. Thanks,

Re: [PERFORM] PostgreSQL performance issues

On Aug 29, 2006, at 7:52 AM, Willo van der Merwe wrote: Hi, We're running PostgreSQL 8.1.4 on CentOS 4 (Linux version 2.6.9-34.0.1.ELsmp). Hardware specs: 2x AMD Dual-Core Opteron 270 Italy 1Ghz HT 2 x 1MB L2 Cache Socket 940 4 GB Registered ECC PC3200 DDR RAM SuperMicro Server-Class 1U AS1020S

Re: [PERFORM] Query Plan - Bitmap Index Scan and Views

On Aug 4, 2006, at 8:15 PM, Tom Lane wrote:Rusty Conover <[EMAIL PROTECTED]> writes: Is there any inherent benefit of using a the IN operator versus  joining a temporary table? Should they offer near equal performance?   It appears bitmap scan's aren't done when matching across a small  temporary t

[PERFORM] Query Plan - Bitmap Index Scan and Views

is not null) left join content_types on (content_types.id = crawled_url.content_type_id and crawled_url.content_type_id is not null) left join http_error_descriptions on (http_error_descriptions.id = crawled_url.http_error_description_id and crawled_url.http_error_description_id is not null) left join charsets on

Re: [PERFORM] Temporary table retains old contents on update eventually causing slow temp file usage.

On Jul 18, 2006, at 6:22 AM, Gavin Sherry wrote: On Tue, 18 Jul 2006, Rusty Conover wrote: Hi, It would seem that doing any changes on a temp table forces a copy of the entire contents of the table to be retained in memory/disk. Is this happening due to MVCC? Is there a way to change this

[PERFORM] Temporary table retains old contents on update eventually causing slow temp file usage.

ried using savepoints and releasing them to see if it would make any difference and it did not, which isn't unexpected. Could pg_relation_size() be incorrect in this case? Cheers, Rusty -- Rusty Conover InfoGears Inc. http://www.infogears.com test=# begin; BEGIN test=# create temp tab

Re: [PERFORM] Temporary table retains old contents on update eventually causing slow temp file usage.

gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) On both the same result happens. Cheers, Rusty -- Rusty Conover InfoGears Inc. http://www.infogears.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http