On Thu, Jan 24, 2013 at 7:43 AM, Prashanth Ranjalkar <
prashant.ranjal...@gmail.com> wrote:
> be no DML operations executing on DWH DB which is mainly used for
> analyzing the data and getting the reports for making business decisions.
> After every data load process, statistices should be updated
Hi Bert,
Yes, ETL process needs to load the data every day into datawarehouse
database from OLTP database and there would be no DML operations executing
on DWH DB which is mainly used for analyzing the data and getting the
reports for making business decisions. After every data load process,
stati
Hello,
I can see why that would be a good practice if you do a daily load, but the
goal is to have a 'live' dwh. with updated statistics every so-many-hours.
Thank you for the information anyway. I guess I will ask more questions
here when time passes. And I'll try to share some knowlegde too! :)
Of course you can also see what the query plan will be without having to run
the query through a standard explain query:
http://www.postgresql.org/docs/9.0/static/sql-explain.html
From: pgsql-admin-ow...@postgresql.org [pgsql-admin-ow...@postgresql.org] on
behalf
On Wed, Jan 23, 2013 at 11:50 PM, Dan Ng wrote:
> Hello,
> I am a newb in Postgres coming from Oracle. Does anyone know if it's
> possible to see the plan being executed by Postgres for an active sql
> statement (from pg_stat_activity). This is to be able to troubleshoot poor
> performing ones an
Hello,
I am a newb in Postgres coming from Oracle. Does anyone know if it's possible
to see the plan being executed by Postgres for an active sql statement (from
pg_stat_activity). This is to be able to troubleshoot poor performing ones and
in Oracle we are able to retrieve such a plan.
Addition
You are correct, it is because I ran initdb as user postgres I am
following you now .. .thanks for the clarification.
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Wednesday, January 23, 2013 11:04 AM
To: Plugge, Joe R.
Cc: pgsql-admin@postgresql.org
Subject:
"Plugge, Joe R." writes:
> Understood, but I thought that the install routine (in this case compiled
> from source on RHEL 6) will create the local user and group named postgres
> and chown the config and data dirs to that
The unmodified Postgres sources will certainly do no such thing.
Understood, but I thought that the install routine (in this case compiled from
source on RHEL 6) will create the local user and group named postgres and chown
the config and data dirs to that
PGDATA=/var/postgresql/log/data
-rw--- 1 postgres postgres 4 Jan 7 15:18 PG_VERSION
drwx-
"Plugge, Joe R." writes:
> Is it possible to install and then subsequently run the postgres engine on
> Linux without creating the postgres user and group? We have some folks
> implementing LDAP that are resistant to creating a postgres account and group
> and would rather create machine speci
*Hi Bert,*
**
*Vaccum analyze operation would be a time consuming activity when it
operates on partitioned table in parent and child relationship by using a
manual vaccum option. When vaccum operation is performed the total
vacuum/analyze time would be total time on completion of the said actvity
o
> Is it possible to install and then subsequently run the postgres engine on
> Linux without creating the postgres user and group? We have some folks
> implementing LDAP that are resistant to creating a postgres account and
> group and would rather create machine specific accounts (like one does f
Yes, at the moment that is still the case.
We are migrating from db2 to postgres, and are still in progress of
migrating our ETL tool. So there isn't much moment in those tables at the
moment.
We got big big problems with db2 auto runstats (sort of auto analyze)
kicking in at random moments, that
Is it possible to install and then subsequently run the postgres engine on
Linux without creating the postgres user and group? We have some folks
implementing LDAP that are resistant to creating a postgres account and group
and would rather create machine specific accounts (like one does for Wi
I'm doing the same thing. In my case, the vacuum part on parent is very
quick while analyzing takes a bit longer since it runs rough analyzes
all children tables. You can see the behavior by "analyze verbose".
Maybe the bigger part of your vacuum/analyze is on analyze so that you
are seeing thi
> autovacuum is still enabled, but we want to avoid autovacuum to hit right
in the day / when the etl is
> working. So that's why we want to shedule it by hand, before autovacuum
starts.
I see.
> Is it a good idea to exclude those tables then? And run only vacuum /
analyze on the child tables, an
Bert wrote:
> I wrote a script to make sure all tables are vacuumed and analyzed every
> evening. This works very
> well.
Autovacuum doesn't do the job for you?
That would save you from worries like the ones you have.
> Does anyone has an idea why in this case the vacuum/analyze takes almost as
Hello,
I first wrote, by mistake, to the sql mailing list. But here is my e-mail:
I wrote a script to make sure all tables are vacuumed and analyzed every
evening. This works very well.
I save in a table the start and end time of a vacuum/analyze. This way I
can measure what tables take a long ti
18 matches
Mail list logo
