Postgres Pro
Downloads
Home   >   mailing lists

Re: Online DW - Mailing list pgsql-hackers

From Sridhar N Bamandlapally
Subject Re: Online DW
Date
Msg-id CAGuFTBVr9ayoqWWLZQUwiCVrniF5V6cf2JogtVePn=-4vv5F7A@mail.gmail.com
Whole thread Raw
In response to Re: Online DW  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Online DW
List pgsql-hackers
Tree view

Ok, let me put this way,

I need every transaction coming from application sync with both production and archive db,
but the transactions I do to clean old data(before 7 days) on production db in daily maintenance window should not sync with archive db,

Archive db need read-only, used for maintaining integrity with other business applications

Issue here is,
1. etl is scheduler, cannot run on every transaction, even if it does, its expensive

2. Materialize view(refresh on commit) or slony, will also sync clean-up transactions

3. Replication is not archive, definitely not option

I say, every online archive db is use case for this.

Thanks
Sridhar
Opentext


On 10 Jun 2016 22:36, "David G. Johnston" <david.g.johnston@gmail.com> wrote:
On Fri, Jun 10, 2016 at 4:11 AM, Sridhar N Bamandlapally <sridhar.bn1@gmail.com> wrote:
Hi

Is there any feature in PostgreSQL where online DW (Dataware housing) is possible ?

am looking for scenario like

1. Production DB will have CURRENT + LAST 7 DAYS data only

2. Archive/DW DB will have CURRENT + COMPLETE HISTORY

expecting something like streaming, but not ETL


​The entire DB couldn't operate this way since not every record has a concept of time and if you use any kind of physical time you are going to have issues as well.

First impression is you want to horizontally partition your "time-impacted" tables so that each partition contains only data having the same ISO Week number in the same ISO Year.

Remove older tables from the inheritance and stick them on a separate tablespace and/or stream them to another database.

As has been mentioned there are various tools out there today that can likely be used to fulfill whatever fundamental need you have.  "Not ETL" is not a need though, its at best a "nice-to-have" unless you are willing to forgo any solution to your larger problem just because the implementation is not optimal.

Unless you define your true goals and constraints its going to be hard to make recommendations.

David J.

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted
Next
From: Andreas Seltenreich
Date:
Subject: Re: [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted