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
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 mode
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 th
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
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
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.
>
"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
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
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) PRIMA
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
> data
10 matches
Mail list logo
