On 07/26/2012 12:31 PM, Gary Webster wrote:
OK, I set "log_statement = "all""
The log grew to 1GB in ~minute! It is dominated by this one statement,
which occurs every ~1.4 sec:
"update WS_BUNDLE set BUNDLE_DATA = $1 where NODE_ID_HI = $2 and
NODE_ID_LO = $3"
parameter $1 is hex, over 6million
On Thu, Jul 26, 2012 at 1:31 PM, Gary Webster wrote:
> OK, I set "log_statement = "all""
> The log grew to 1GB in ~minute! It is dominated by this one statement,
> which occurs every ~1.4 sec:
> "update WS_BUNDLE set BUNDLE_DATA = $1 where NODE_ID_HI = $2 and NODE_ID_LO
> = $3"
> parameter $1 is
On Wed, Jul 25, 2012 at 2:44 PM, Joshua D. Drake wrote:
>
> On 07/25/2012 11:37 AM, Gary Webster wrote:
>
> This is a cluster issue, not a database issue. So if you have an
>> idnle in transaction, then it is affecting your JCR schema as well.
>>
>> OK, how do I track/debug/stop the "idle
On 07/25/2012 11:37 AM, Gary Webster wrote:
This is a cluster issue, not a database issue. So if you have an
idnle in transaction, then it is affecting your JCR schema as well.
OK, how do I track/debug/stop the "idle in transaction"s ?
Well idle in transaction is ALWAYS a code issue.
On Tue, Jul 24, 2012 at 1:41 PM, Joshua D. Drake wrote:
>
> On 07/24/2012 08:58 AM, Gary Webster wrote:
>
>> Hello.
>> Thanks for the response.
>>
>> There are several 'idle in transaction' on this server/app, but to a
>> different db/schema.
>>
>
> This is a cluster issue, not a database issue. S
On 07/24/2012 08:58 AM, Gary Webster wrote:
Hello.
Thanks for the response.
There are several 'idle in transaction' on this server/app, but to a
different db/schema.
This is a cluster issue, not a database issue. So if you have an idnle
in transaction, then it is affecting your JCR schema as
Gary Webster writes:
> By "routine maintenance", do you mean autovacuum, or something else?
> Autovacuum does appear to usually get 'auto-canceled' by a lock.
That's bad and you should look into the reason why it happens. Ordinary
DML (CRUD) operations should not kick autovac off a table. If it
Hello.
Thanks for the response.
There are several 'idle in transaction' on this server/app, but to a
different db/schema.
The "repository" (JCR) schema has only a few 'idle', none 'in transaction' .
By "routine maintenance", do you mean autovacuum, or something else?
Autovacuum does appear to usu
Hello.
Thanks for the response.
Autovacuum is set VERY aggressive.
However, it does not help with the ws_bundle Toast table.
A manual _full_ vacuum (not recommended?) does do the deed.
However, it often gives this error:
ERROR: missing chunk number 0 for toast value 639113 in pg_toast_533386
BT
On 07/24/2012 05:13 AM, Gary Webster wrote:
Hello. I'm hoping someone has seen this before.
We are trying to use Postgres Plus v9.1.3 as the Persistence Manager
in Jackrabbit (Apache JCR) clustering
(http://wiki.apache.org/jackrabbit/Clustering).
Whenever the JCR is under load, the ws_bundle T
On 07/23/2012 02:13 PM, Gary Webster wrote:
Hello. I'm hoping someone has seen this before.
We are trying to use Postgres Plus v9.1.3 as the Persistence Manager in
Jackrabbit (Apache JCR) clustering
(http://wiki.apache.org/jackrabbit/Clustering).
Whenever the JCR is under load, the ws_bundle TO
Hello. I'm hoping someone has seen this before.
We are trying to use Postgres Plus v9.1.3 as the Persistence Manager in
Jackrabbit (Apache JCR) clustering (
http://wiki.apache.org/jackrabbit/Clustering).
Whenever the JCR is under load, the ws_bundle TOAST table in the
repository schema, grows out
Tom Lane wrote:
Isabella Ghiurea writes:
> The issue may be with pg_size_pretty() results, I don't have details
> knowledge of this function.
I doubt it, that's a pretty simple function ... but if you don't trust
it, just remove the pg_size_pretty call and look directly at the output
of th
Isabella Ghiurea writes:
> The issue may be with pg_size_pretty() results, I don't have details
> knowledge of this function.
I doubt it, that's a pretty simple function ... but if you don't trust
it, just remove the pg_size_pretty call and look directly at the output
of the size functions.
>
| 584 kB
>
>
>
>
> *** OR : check for the biggest tables+index size:
> SELECT ' Top 20 biggest tables and indexes'
> ;
> SELECT nspname || '.' || relname AS "relation",
>pg_size_pretty(pg_relation_size(nspname || '.&#x
Isabella Ghiurea writes:
> SELECT nspname || '.' || relname AS
> "relation",pg_size_pretty(pg_total_relation_size(nspname || '.' || relname))
> AS "s
> ize"
> FROM pg_class C
> LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
> ORDER BY pg_total_relation_size(nspname || '.' || relname) D
artifact_i1 | 171 MB
caom.simpleobservation| 165 MB
caom.spatialentity_i1 | 162 MB
caom.positionsample | 110 MB
caom.plane_psi2 | 86 MB
caom.temporalentity | 77 MB
caom.spectralentity | 68 MB
caom.plane_energy_i1 | 67 MB
caom.plane_time_i1| 58 MB
caom.pl
Isabella Ghiurea writes:
> SELECT nspname || '.' || relname AS
> "relation",pg_size_pretty(pg_total_relation_size(nspname || '.' ||
> relname)) AS "s
> ize"
> FROM pg_class C
> LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
> ORDER BY pg_relation_size(nspname || '.' || relname) DESC
Hi All,
Please, see more info my env: PG 8.3.6 on RHE5-64bits.
1. there are more than one schemas, but the size of the tables is close
to 30-40kB, see some samples
schemaname | tablename | size_pretty | total_size_pretty
+-+-+---
tap_sche
How would one check for catalog bloat? And, if bloated, would unloading
and reloading the database
fix it?
Naomi
3. Bloat in other system catalogs. 5GB of catalog bloat would be
pretty awful, but maybe that's what it is.
Try that last query without the namespace restrictions.
Naomi Walker writes:
> How would one check for catalog bloat?
Like I said:
>> Try that last query without the namespace restrictions.
Isabella excluded pg_catalog, so if that's where the problem is,
that's why she didn't see it. But let's see the data before
discussing how to fix it...
Isabella Ghiurea writes:
> I'm trying to understand why there are GB's difference when checking
> for db size using pg_size_pretty() and querying for tables + indexes
> size. .
You are not counting everything --- the total DB size is clearly 12GB,
so the question is where are the other 5.
Hi Pg Admin list.
I'm trying to understand why there are GB's difference when checking
for db size using pg_size_pretty() and querying for tables + indexes
size. .
The sum of tables +index sizes is showing as aprox 6.5GB and
pg_size_pretty(dbname) is coming as 12GB, this are the resul
> Hi all. I'm not a good DB admin , thats why I'm posting to this list !
> How can I figure out the size of a database or table ???
It was easier in older versions of postgresql to perform a `du -h` on
the directory that corresponded to the database name. However now they
are named by some type o
> Hi all. I'm not a good DB admin , thats why I'm posting to this list !
> How can I figure out the size of a database or table ???
It was easier in older versions of postgresql to perform a `du -h` on
the directory that corresponded to the database name. However now they
are named by some type o
Hi all. I'm not a good DB admin , thats why I'm posting to this list !
How can I figure out the size of a database or table ???
--
Leandro Rodrigo Saad Cruz
InterBusiness tecn. e serv.
Sao Paulo - Brasil
begin:vcard
n:Rodrigo Saad Cruz;Leandro
x-mozilla-html:FALSE
org:Inter Business;IT
adr:;;;
26 matches
Mail list logo
