Hi All;
I know part of the function name "get_registration_auth" (this part of its
name) while its name might be "voipdb_get_registration_auth_gnugk", how can I
search for the functions that its name contain "get_registration_auth"?
Also if I donot know if "get_registration_auth" if a function
We are testing 8.4 and noticed that the performance of
select max(indexed_col) from parent_Table
is the same (slow) as postgres 8.1.x ( our current version).The
child tables are huge and the indexed_col is not the basis for
partitioning.
I remember that this was an issue from an earlier thre
On Tue, Aug 18, 2009 at 06:30:15AM -0700, Anj Adu wrote:
> We are testing 8.4 and noticed that the performance of
>
> select max(indexed_col) from parent_Table
>
> is the same (slow) as postgres 8.1.x ( our current version).The
> child tables are huge and the indexed_col is not the basis for
What is your constraint_exclusion config set to on your new instance?
-Original Message-
From: pgsql-admin-ow...@postgresql.org
[mailto:pgsql-admin-ow...@postgresql.org] On Behalf Of Anj Adu
Sent: Tuesday, August 18, 2009 8:30 AM
To: pgsql-admin@postgresql.org
Subject: [ADMIN] select max(
On Tue, Aug 18, 2009 at 08:38:28AM -0500, Plugge, Joe R. wrote:
> What is your constraint_exclusion config set to on your new instance?
>
Even with it set to the default of "partition", the query does
not push the max() down to the child tables and does a sequential
scan of the tables and does not
bilal ghayyad wrote:
> I know part of the function name "get_registration_auth" (this part
> of its name) while its name might be
> "voipdb_get_registration_auth_gnugk", how can I search for the
> functions that its name contain "get_registration_auth"?
>From within psql you can type:
\df *
Hello,
I'm working on a warm standby system, and we would like to stick with
the RHEL5 distributed version of postgres, which is still 8.1.
I can setup the system to a point where it's adequate for disaster
recovery, but I'm not comfortable keeping the systems in sync for
failover, maintenance, o
James,
You really, really, really should upgrade to a more recent
release. The list of improvements and bugfixes is long and
well worth having. 8.1 was released 4 years ago. If you
cannot, please, please make certain that you are running
the latest point release -- regardless of what is shipping
w
Thanks Ken. The more I think about it, the more I feel we should move
away from upstream, and pull the latest version for this.
So on with newer versions -
When using the built-in systems for warm standby, how do I ensure that
the latest transactions have been archived? Does a clean shutdown
flus
We have a partitioned table structure where the partitions are created
on a daily basis. One of the inserts into the daily partition failed
(crashed) ..the partition was empty after the crash. We did a vacuum
of the partition and it takes very long (over 30 minutes).
Postgres 8.1.2 ... vacuum_c
On Tue, Aug 18, 2009 at 12:09:25PM -0400, james bardin wrote:
> Thanks Ken. The more I think about it, the more I feel we should move
> away from upstream, and pull the latest version for this.
>
>
> So on with newer versions -
> When using the built-in systems for warm standby, how do I ensure t
Hi all;
we have a large table that gets a lot of churn throughout the day.
performance has dropped off a cliff. A vacuum verbose on the table showed us
this:
INFO: "action_rollup_notifier": found 0 removable, 34391214 nonremovable row
versions in 152175 pages
DETAIL: 22424476 dead row vers
Kevin Kempter writes:
> INFO: "action_rollup_notifier": found 0 removable, 34391214 nonremovable row
> versions in 152175 pages
> DETAIL: 22424476 dead row versions cannot be removed yet.
> Anyone have any suggestions per why these rows cannot be removed yet?
You've got an open transaction that
Kevin Kempter wrote:
> INFO: "action_rollup_notifier": found 0 removable, 34391214
> nonremovable row versions in 152175 pages
> DETAIL: 22424476 dead row versions cannot be removed yet.
> There were 0 unused item pointers.
> 2 pages contain useful free space.
> 0 pages are entirely empty.
> An
On Tuesday 18 August 2009 13:37:12 Tom Lane wrote:
> Kevin Kempter writes:
> > INFO: "action_rollup_notifier": found 0 removable, 34391214 nonremovable
> > row versions in 152175 pages
> > DETAIL: 22424476 dead row versions cannot be removed yet.
> >
> > Anyone have any suggestions per why these r
On Tue, Aug 18, 2009 at 2:41 PM, Kevin
Kempter wrote:
> On Tuesday 18 August 2009 13:37:12 Tom Lane wrote:
>> Kevin Kempter writes:
>> > INFO: "action_rollup_notifier": found 0 removable, 34391214 nonremovable
>> > row versions in 152175 pages
>> > DETAIL: 22424476 dead row versions cannot be remo
I'm running a vacuum full on a table due to excessive updates/deletes. It's
been running for more than an hour (it's about 3Gig in size)
2 questions:
1) is there any way to gain some visibility per the progress of the vacuum
full
2) can I safely kill the vacuum full and do a dump, drop table,
Kevin Kempter wrote:
> 1) is there any way to gain some visibility per the progress of the
> vacuum full
None that I know of, short of attaching to the backend process with a
debugger and poking at its guts.
> 2) can I safely kill the vacuum full and do a dump, drop table,
> restore instead
"Kevin Grittner" wrote:
> Killing a VACUUM FULL
To be clear, cancel the query on the backend, don't kill the process.
Some versions of PostgreSQL can corrupt data if a backend process is
killed.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to y
Kevin Grittner wrote:
> Kevin Kempter wrote:
> > 2) can I safely kill the vacuum full and do a dump, drop table,
> > restore instead?
>
> Killing a VACUUM FULL can leave the table or its indexes more bloated
> than when you started, but it should have no other negative impact. I
> have genera
20 matches
Mail list logo
