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
Tom Lane napsal(a):
Michal Taborsky <[EMAIL PROTECTED]> writes:
We are facing a performance problem with views consisting of several
unioned tables. The simplified schema is as follows:
Perhaps you should show us the real schema, because I cannot duplicate
your complaint on the toy ca
Hello everyone.
We are facing a performance problem with views consisting of several
unioned tables. The simplified schema is as follows:
CREATE TABLE foo (
foo_object_id bigint,
link_id bigint,
somedatatext,
PRIMARY KEY (foo_object_id) );
CRE
I managed, by extensive usage of temporary tables, to totally bloat
pg_attribute. It currently has about 4 pages with just 3000 tuples.
The question is, how to restore it to it's former beauty? With ordinary
table I'd just CLUSTER it, but alas! I cannot do that with system
catalog. I always
E, so Postgres knows about the structure of the
data.
--
Michal Taborsky
http://www.taborsky.cz
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
t 300 users, you need to set max_connections
to 300 + superuser_reserved_connections.
--
Michal Taborsky
http://www.taborsky.cz
---(end of broadcast)---
TIP 8: explain analyze is your friend
it, that there is nothing I can do about
it. Well, we'll have to live with that, at least until 7.5.
Thanks of the help all the same.
--
Michal Taborsky
http://www.taborsky.cz
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, p
ly once per pageload.
--
Michal Taborsky
http://www.taborsky.cz
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
14 matches
Mail list logo
