Date: Fri, 28 Feb 2014 17:12:20 +0100 (CET)
From: Jan Ostrochovsky <ostrochovsky@mobiletech.sk>
To: David Johnston <polobo@yahoo.com>
Cc: pgsql-sql@postgresql.org
Message-ID: <1083597622.602688.1393603940121.JavaMail.root@mobiletech.sk>
In-Reply-To: <1393601978985-5794056.post@n5.nabble.com>
Subject: Re: how to effectively SELECT new "customers"
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----=_Part_602687_1418346646.1393603940120"
Precedence: bulk
Sender: pgsql-sql-owner@postgresql.org

------=_Part_602687_1418346646.1393603940120
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

----- Original Message -----

> From: "David Johnston" <polobo@yahoo.com>

> 9.3 adds materialized views syntax and functionality directly into
> PostgreSQL but you can "roll your own" in any version and that is
> what I
> would suggest.

> I would probably focus on getting a single reporting period to
> execute
> performantly and just use a loop to build up the materialized view
> period-by-period.

> I don't know how you want to go about dealing with your payment
> channel
> since it depends on whether a customer can make use of more than one
> and
> whether their "new-ness" is impacted by such.

> Incorporating other data is as simple as building the different
> pieces and
> joining them together into a final output; usually through a series
> of
> CTEs/WITH sub-queries.

> David J.

> --
> View this message in context:
> http://postgresql.1045698.n5.nabble.com/how-to-effectively-SELECT-new-customers-tp5793867p5794056.html
> Sent from the PostgreSQL - sql mailing list archive at Nabble.com.

> --
> Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-sql

customer may have various payment channels during the time... new-ness is not impacted by the channel, it does not matter from which channel, all customer_id occurences count (in determined filtration criteria, e.g. town, service, subservice) 

and there are also other filtration and grouping criteria (town, service, subservice) and user of reporting tool should have possibility to select from those... there are dozens of services and subservices, cca 4 payment channels, dozens of towns... therefore preprocessing through materialized view (if I understand your suggestion correctly), would contain a lot of combinations, it seems quite complex for me in these circumstances 

I also considered WITH (CTEs) previously, I will rethink it yet, after these your recommendations 

thanks 
------=_Part_602687_1418346646.1393603940120
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: times new roman,new york,times,serif; font-size: =
12pt; color: #000000'><hr id=3D"zwchr"><blockquote style=3D"border-left:2px=
 solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:norm=
al;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-=
serif;font-size:12pt;" id=3D"DWT697"><b>From: </b>"David Johnston" &lt;polo=
bo@yahoo.com&gt;<br><br>9.3 adds materialized views syntax and functionalit=
y directly into<br>PostgreSQL but you can "roll your own" in any version an=
d that is what I<br>would suggest.<br><br>I would probably focus on getting=
 a single reporting period to execute<br>performantly and just use a loop t=
o build up the materialized view<br>period-by-period.<br><br>I don't know h=
ow you want to go about dealing with your payment channel<br>since it depen=
ds on whether a customer can make use of more than one and<br>whether their=
 "new-ness" is impacted by such.<br><br>Incorporating other data is as simp=
le as building the different pieces and<br>joining them together into a fin=
al output; usually through a series of<br>CTEs/WITH sub-queries.<br><br>Dav=
id J.<br><br><br><br><br><br>--<br>View this message in context: http://pos=
tgresql.1045698.n5.nabble.com/how-to-effectively-SELECT-new-customers-tp579=
3867p5794056.html<br>Sent from the PostgreSQL - sql mailing list archive at=
 Nabble.com.<br><br><br>-- <br>Sent via pgsql-sql mailing list (pgsql-sql@p=
ostgresql.org)<br>To make changes to your subscription:<br>http://www.postg=
resql.org/mailpref/pgsql-sql<br></blockquote>customer may have various paym=
ent channels during the time... new-ness is not impacted by the channel, it=
 does not matter from which channel, all customer_id occurences count (in d=
etermined filtration criteria, e.g. town, service, subservice)<div><br></di=
v><div>and there are also other filtration and grouping criteria (town, ser=
vice, subservice) and user of reporting tool should have possibility to sel=
ect from those... there are dozens of services and subservices, cca 4 payme=
nt channels, dozens of towns... therefore preprocessing through materialize=
d view (if I understand your suggestion correctly), would contain a lot of =
combinations, it seems quite complex for me in these circumstances</div><di=
v><br></div><div>I also considered WITH (CTEs) previously, I will rethink i=
t yet, after these your recommendations</div><div><br></div><div>thanks</di=
v></div></body></html>
------=_Part_602687_1418346646.1393603940120--