Re: [PERFORM] Cursor fetch performance issue

2012-01-24 Thread Tony Capobianco
Here's the explain: pg=# explain select getMemberAdminPrevious_sp(247815829, 1,'test.em...@hotmail.com', 'Email', 'Test'); QUERY PLAN -- Result (cost=0.00..0.26 rows=1 width=0) (1 row) Time: 1.167 ms There was discussion

Re: [PERFORM] Cursor fetch performance issue

2012-01-24 Thread Tony Capobianco
ecute the function? On Tue, 2012-01-24 at 21:47 +0100, Pavel Stehule wrote: > Hello > > 2012/1/24 Tony Capobianco : > > We are migrating our Oracle warehouse to Postgres 9. > > > > This function responds well: > > > > pg=# select public.getMemberAdminPrevio

[PERFORM] Cursor fetch performance issue

2012-01-24 Thread Tony Capobianco
We are migrating our Oracle warehouse to Postgres 9. This function responds well: pg=# select public.getMemberAdminPrevious_sp2(247815829, 1,'test.em...@hotmail.com', 'email', 'test'); getmemberadminprevious_sp2 (1 row) Time: 7.549 ms However, when testing, thi

Re: [PERFORM] Oracle v. Postgres 9.0 query performance

2011-06-08 Thread Tony Capobianco
Oooo...some bad math there. Thanks. On Wed, 2011-06-08 at 12:38 -0700, Samuel Gendler wrote: > > > On Wed, Jun 8, 2011 at 12:03 PM, Tony Capobianco > wrote: > My current setting is 22G. According to some documentation, I > want to > set effectiv

Re: [PERFORM] Oracle v. Postgres 9.0 query performance

2011-06-08 Thread Tony Capobianco
? Most of our other etl processes are running fine, however I'm curious if I could see a significant performance boost by reducing the effective_cache_size. On Wed, 2011-06-08 at 13:03 -0400, Tom Lane wrote: > Tony Capobianco writes: > > Well, this ran much better. However, I'

Re: [PERFORM] Oracle v. Postgres 9.0 query performance

2011-06-08 Thread Tony Capobianco
wrote: > Hello > > what is your settings for > > random_page_cost, seq_page_cost and work_mem? > > Regards > > Pavel Stehule > > 2011/6/8 Tony Capobianco : > > Here's the explain analyze: > > > > pg_dw=# explain analyze CREATE

Re: [PERFORM] Oracle v. Postgres 9.0 query performance

2011-06-08 Thread Tony Capobianco
> Seq Scan on ecr_sents s (cost=0.00..8.79 rows=479 width=4) (actual time=0.010..0.121 rows=479 loops=1) Total runtime: 167279.950 ms On Wed, 2011-06-08 at 11:51 -0400, Stephen Frost wrote: > * Tony Capobianco (tcapobia...@prospectiv.com) wrote: > > HashAggregate (cost=43911

Re: [PERFORM] Oracle v. Postgres 9.0 query performance

2011-06-08 Thread Tony Capobianco
Here's the explain analyze: pg_dw=# explain analyze CREATE TABLE ecr_opens with (FILLFACTOR=100) as select o.emailcampaignid, count(memberid) opencnt from openactivity o,ecr_sents s where s.emailcampaignid = o.emailcampaignid group by o.emailcampaignid; QUERY PLAN

Re: [PERFORM] Oracle v. Postgres 9.0 query performance

2011-06-08 Thread Tony Capobianco
.79 rows=479 width=4) Yikes. Two sequential scans. On Wed, 2011-06-08 at 11:33 -0400, Tom Lane wrote: > Tony Capobianco writes: > > pg_dw=# explain CREATE TABLE ecr_opens with (FILLFACTOR=100) > > pg_dw-# as > > pg_dw-# select o.emailcampaignid, count(memberid) opencnt

[PERFORM] Oracle v. Postgres 9.0 query performance

2011-06-08 Thread Tony Capobianco
We are thiis close to moving our datawarehouse from Oracle to Postgres. This query is identical on both systems, but runs much, much faster on Oracle. Our Postgres host has far superior hardware and tuning parameters have been set via pgtune. Most everything else runs faster in Postgres, exc

Re: [PERFORM] oracle to psql migration - slow query in postgres

2010-10-15 Thread Tony Capobianco
Very true Igor! Free is my favorite price. I'll figure a way around this issue. Thanks for your help. Tony On Fri, 2010-10-15 at 14:54 -0400, Igor Neyman wrote: > > -Original Message- > > From: Tony Capobianco [mailto:tcapobia...@prospectiv.com] > > Sent: Fri

Re: [PERFORM] oracle to psql migration - slow query in postgres

2010-10-15 Thread Tony Capobianco
identified by operation id): --- 4 - filter("EMAILBOUNCED"=0 AND "EMAILOK"=1) 16 rows selected. On Fri, 2010-10-15 at 13:43 -0400, Igor Neyman wrote: > > > -Original Message- > > From: Tony Capobian

Re: [PERFORM] oracle to psql migration - slow query in postgres

2010-10-15 Thread Tony Capobianco
The recommendations on the numeric columns are fantastic. Thank you very much. We will revisit our methods of assigning datatypes when we migrate our data over from Oracle. Regarding the full table scans; it appears inevitable that full table scans are necessary for the volume of data involved an

[PERFORM] oracle to psql migration - slow query in postgres

2010-10-14 Thread Tony Capobianco
We are in the process of testing migration of our oracle data warehouse over to postgres. A potential showstopper are full table scans on our members table. We can't function on postgres effectively unless index scans are employed. I'm thinking I don't have something set correctly in my postgres