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
