It looks like my primary slowdown on that query was the timestamp
trigger. However, even after removing that trigger, and ensuring that
all of my referencing tables had their foreign keys indexed, a simple
update of one column on 244451 records took 14 minutes. Given the specs
I mentioned in
John McCawley <[EMAIL PROTECTED]> writes:
> In looking at the "\d tbl_claim" output, there is something odd I
> notice. I have many foreign keys (the claim_id in tbl_claim is
> referenced by 12 or so other tables, and tbl_claim references about 6 or
> so tables by their _id)
It seems a good be
Tom Lane wrote:
The differential would have to be index updates or triggers fired by the
UPDATE. I'd bet on
the latter, but since you've told us zip about your schema or what PG
version this is, it's impossible to speculate further...
This is my development machine. I'm running PostgreSQ
On 12/28/05, John McCawley <[EMAIL PROTECTED]> wrote:
> I am currently having a problem with a query never finishing (or at
> least not in a reasonable amount of time.) I have had similar problems
> to this in Postgres over the past several years, and I have always found
> workarounds. This time
John McCawley <[EMAIL PROTECTED]> writes:
> I am currently having a problem with a query never finishing (or at
> least not in a reasonable amount of time.) I have had similar problems
> to this in Postgres over the past several years, and I have always found
> workarounds. This time I'd like
I am currently having a problem with a query never finishing (or at
least not in a reasonable amount of time.) I have had similar problems
to this in Postgres over the past several years, and I have always found
workarounds. This time I'd like to actually understand what is happening.
I have
