Honza Novak napsal(a):
And my questions:
1. Does someone hes similar experience? or clue what to do with it?
Sure, this is considered "normal" behavior for web applications. The
solution is to use connection pooling.
2. What is correct setup of postgresql backend serving data for many
(4+)
CARMODA napsal(a):
has anyone here had any good/bad experiences clustering & load balancing
a PostgreSQL server on Redhat (ES)?
We have recently successfully rolled-out a solution consisting of two
PostgreSQL database backends replicated by Slony. The backends are
accessed from a bunch of appli
Markus Schaber napsal(a):
Hi, Michal,
Michal Taborsky - Internet Mall wrote:
When using this view, you are interested in tables, which have the
"bloat" column higher that say 2.0 (in freshly dump/restored/analyzed
database they should all be around 1.0).
I just noticed some
Brad Nicholson napsal(a):
I just put together a view, which helps us in indentifying which
database tables are suffering from space bloat, ie. they take up much
Are you sure you haven't reinvented the wheel? Have you checked out
contrib/pgstattuple ?
Well, I wasn't aware of it, so I guess
I just put together a view, which helps us in indentifying which
database tables are suffering from space bloat, ie. they take up much
more space than they actually should. I though this might be useful for
some folk here, because the questions about bloat-related performance
degradation are qu
Tom Lane napsal(a):
Michal Taborsky - Internet Mall <[EMAIL PROTECTED]> writes:
SELECT product.product_id
FROM action
JOIN product ON (product.product_id=action.product_id)
WHERE action.shop_group_id=1
AND EXISTS (SELECT 1
FROM catalog.product_program
Hello everyone.
My (simplified) database structure is:
a) table product (15 rows)
product_id BIGINT PRIMARY KEY
title TEXT
...
b) table action (5000 rows)
action_id BIGINT PRIMARY KEY
product_id BIGINT, FK to product
shop_group_id INTEGER (there are about 5 groups, distributed about e
