Re: [PERFORM] Performance issues

On 14.3.2015 00:28, Vivekanand Joshi wrote: > Hi Guys, > > So here is the full information attached as well as in the link > provided below: > > http://pgsql.privatepaste.com/41207bea45 > > I can provide new information as well. Thanks. We still don't have EXPLAIN ANALYZE - how long was the qu

Re: [PERFORM] Performance issues

Hi Guys, So here is the full information attached as well as in the link provided below: http://pgsql.privatepaste.com/41207bea45 I can provide new information as well. Would like to see if queries of these type can actually run in postgres server? If yes, what would be the minimum requirement

Re: [PERFORM] Performance issues

On Fri, Mar 13, 2015 at 4:03 PM, Varadharajan Mukundan wrote: >> We might even consider taking experts advice on how to tune queries and >> server, but if postgres is going to behave like this, I am not sure we would >> be able to continue with it. >> >> Having said that, I would day again that I

Re: [PERFORM] Postgres inconsistent use of Index vs. Seq Scan

"Jim Carroll" writes: > I'm having difficulty understanding what I perceive as an inconsistency in > how the postgres parser chooses to use indices. We have a query based on NOT > IN against an indexed column that the parser executes sequentially, but > when we perform the same query as IN, it us

Re: [PERFORM] Performance issues

> We might even consider taking experts advice on how to tune queries and > server, but if postgres is going to behave like this, I am not sure we would > be able to continue with it. > > Having said that, I would day again that I am completely new to this > territory, so I might miss lots and lots

[PERFORM] Postgres inconsistent use of Index vs. Seq Scan

I'm having difficulty understanding what I perceive as an inconsistency in how the postgres parser chooses to use indices. We have a query based on NOT IN against an indexed column that the parser executes sequentially, but when we perform the same query as IN, it uses the index. I've created

Re: [PERFORM] Performance issues

On 13.3.2015 21:46, Vivekanand Joshi wrote: > Since I was doing it only for the testing purposes and on a > development server which has only 8 GB of RAM, I used only 10m rows. > But the original table has 1.5 billion rows. We will obviously be > using a server with very high capacity, but I am no

Re: [PERFORM] Performance issues

Since I was doing it only for the testing purposes and on a development server which has only 8 GB of RAM, I used only 10m rows. But the original table has 1.5 billion rows. We will obviously be using a server with very high capacity, but I am not satisfied with the performance at all. This might

Re: [PERFORM] Performance issues

Hi, On 13.3.2015 20:59, Vivekanand Joshi wrote: > I am really worried about the performance of PostgreSQL as we have > almost 1.5 billion records in promotion history table. Do you guys In the previous message you claimed the post table has 10M rows ... > really think PostgreSQL can handle this

Re: [PERFORM] Performance issues

I am really worried about the performance of PostgreSQL as we have almost 1.5 billion records in promotion history table. Do you guys really think PostgreSQL can handle this much load. We have fact tables which are more than 15 GB in size and we have to make joins with those tables in almost every

[PERFORM] Anyone have experience using PG on a NetApp All-Flash FAS8000?

The reason I ask is that it seems to support deduplication/compression. I was wondering if this would have any performance implications of PG operations. Thanks, M.? Mel Llaguno * Staff Engineer - Team Lead Office: +1.403.264.9717 x310 www.coverity.com

Re: [PERFORM] Performance issues

If the s_f_promotion_history table will have a explosive growth, then its worth considering partitioning by date and using constraint exclusion to speed up the queries. Else, it makes sense to get started with multiple partial index (like, have a index for each week or something like that. You may

Re: [PERFORM] Performance issues

10 million records in s_f_promotion_history table. *From:* Varadharajan Mukundan [mailto:srinath...@gmail.com] *Sent:* Friday, March 13, 2015 6:29 PM *To:* vjo...@zetainteractive.com *Cc:* pgsql-performance@postgresql.org *Subject:* Re: [PERFORM] Performance issues Hi Vivekanand, >From the

Re: [PERFORM] Performance issues

Hi Vivekanand, >From the query plan, we can see that good amount of time is spent in this line -> Seq Scan on public.s_f_promotion_history base (cost=0.00..283334.00 rows=1296 width=74) Output: base.promo_hist_id, base.target_id, base.audience_member_id, base.touchpoint_execution_i

[PERFORM] Performance issues

Hi Team, I am a novice to this territory. We are trying to migrate few jasper reports from Netezza to PostgreSQL. I have one report ready with me but queries are taking too much time. To be honest, it is not giving any result most of the time. The same query in Netezza is running in less