Skip site navigation (1) Skip section navigation (2)

Re: Delete query takes exorbitant amount of time

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>,Karim Nassar <karim(dot)nassar(at)NAU(dot)EDU>,Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>,pgsql-performance(at)postgresql(dot)org
Subject: Re: Delete query takes exorbitant amount of time
Date: 2005-03-25 21:25:09
Message-ID: 12831.1111785909@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> On Fri, 25 Mar 2005, Simon Riggs wrote:
>> Could it be that because PostgreSQL has a very highly developed sense of
>> datatype comparison that we might be taking this to extremes? Would any
>> other RDBMS consider two different datatypes to be comparable?

> We do have a broader comparable than the spec.

However, the set of comparisons that we can presently support *with
indexes* is narrower than the spec, so rejecting nonindexable cases
would be a problem.

It's worth noting also that the test being discussed checks whether the
PK index is usable for testing the RI constraint.  In the problem that
started this thread, the difficulty is lack of a usable index on the FK
column, not the PK (because that's the table that has to be searched to
do a delete in the PK table).  We cannot enforce that there be a usable
index on the FK column (since indexes on the FK table may not have been
built yet when the constraint is declared), and shouldn't anyway because
there are reasonable usage patterns where you don't need one.

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Karim NassarDate: 2005-03-25 21:47:44
Subject: Re: Delete query takes exorbitant amount of time
Previous:From: Matthew T. O'ConnorDate: 2005-03-25 21:12:27
Subject: Re: lazy_update_relstats considered harmful (was Re: [PERFORM]

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group