On Fri, 2007-04-13 at 14:01 -0600, Dan Harris wrote:
Is there a pg_stat_* table or the like that will show how bloated an index
is?
I am trying to squeeze some disk space and want to track down where the worst
offenders are before performing a global REINDEX on all tables, as the
database
Consider these two very similar schemas:
Schema 1:
CREATE TABLE foo (
id serial PRIMARY KEY,
frobnitz character(varying 100) NOT NULL UNIQUE
);
CREATE TABLE bar (
id serial PRIMARY KEY,
foo_id int REFERENCES foo(id)
)
Schema 2:
CREATE TABLE foo (
frobnitz character(varying 100)
In response to Kynn Jones [EMAIL PROTECTED]:
Consider these two very similar schemas:
Schema 1:
CREATE TABLE foo (
id serial PRIMARY KEY,
frobnitz character(varying 100) NOT NULL UNIQUE
);
CREATE TABLE bar (
id serial PRIMARY KEY,
foo_id int REFERENCES foo(id)
)
Dann Corbit [EMAIL PROTECTED] writes:
Instead of sorting, I suggest the quickselect() algorithm, which is
O(n).
What for? Common cases have less than half a dozen entries. That is
not the place we need to be spending engineering effort --- what we
need to worry about is what's the choice
Ron [EMAIL PROTECTED] writes:
One of the reasons for the wide variance in suggested values for pg
memory use is that pg 7.x and pg 8.x are =very= different beasts.
If you break the advice into pg 7.x and pg 8.x categories, you find
that there is far less variation in the suggestions.
Bottom
Alvaro Herrera [EMAIL PROTECTED] writes:
I think the concern about condition redundancy should be attacked
separately. How about just comparing whether they have common prefixes
of conditions? I admit I don't understand what would happen with
indexes defined like (lower(A), B, C) versus (A,
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Has anyone got any thoughts about the best way to do this?
How about doing both: sort the index by index scan cost; then pick the
first index on the list and start adding indexes when they lower the
cost. When adding each index,
I have performance problem with the following simple update query:
UPDATE posts
SET num_views = num_views + 1
WHERE post_id IN (2526,5254,2572,4671,25);
The table posts is a large table with a number of foreign keys (FK).
It seems that the FK triggers for the table are evaluated even
cluster [EMAIL PROTECTED] writes:
It seems that the FK triggers for the table are evaluated even though
none of the FK columns are altered.
Hm, they're not supposed to be, at least not in reasonably modern
PG releases (and one that breaks out trigger runtime in EXPLAIN ANALYZE
should be modern
On 2007-04-15, Tom Lane [EMAIL PROTECTED] wrote:
cluster [EMAIL PROTECTED] writes:
It seems that the FK triggers for the table are evaluated even though
none of the FK columns are altered.
Hm, they're not supposed to be, at least not in reasonably modern
PG releases (and one that breaks out
10 matches
Mail list logo
