gt;> For example in the first message you mentioned that select from the
>> S_V_D_CAMPAIGN_HIERARCHY view takes ~9 minutes, so start with that. Give
>> us EXPLAIN ANALYZE for that query.
>>
>> Few more comments:
>>
>> (1) You're using CTEs - be aware t
Hi Mel,
I don't have any experience in NetApp storage systems, but if
compression / deduplication is the only point for which you're
consider NetApp, then do consider FS like ZFS or btrfs which can do
deduplication as well as compression on normal disks. Here are few
reports of running Postgres o
> 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
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
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
Hi Jeff,
Instead what I get is the index only scan (to provide order) feeding into a
> Group.
>
That's interesting. We tested out in two versions of Postgres (9.2 and 9.3)
in different Mac machines and ended up with index-only scan only after the
partial index. I remember doing a vacuum full anal
Hi Jeff,
It looks like the original emailer wrote a query that the planner is not
> smart enough to plan properly (A known limitation of that kind of query).
> He then made a bunch of changes, none of which worked. He then re-wrote
> the query into a form for which the planner does a better job
Sorry that i just joined the list and have to break the thread to reply to
Tom Lane's response on this @
http://www.postgresql.org/message-id/13741.1396275...@sss.pgh.pa.us
Note that the indexscan is actually *slower* than the seqscan so far as
> the table access is concerned; if the table were b
