Hello,
I have a main table and a lot of details tables that reference the
main one.
Every time I delete a record from the main table, a check is done on
every details table that contain a foreign key toward main table.
This is a simplified schema:
create table main (
type varchar,
serial
On 12/1/2014 9:23 AM, Giuseppe Sacco wrote:
Hello,
I have a main table and a lot of details tables that reference the
main one.
Every time I delete a record from the main table, a check is done on
every details table that contain a foreign key toward main table.
This is a simplified schema:
Il giorno lun, 01/12/2014 alle 09.49 -0600, Andy Colson ha scritto:
On 12/1/2014 9:23 AM, Giuseppe Sacco wrote:
Hello,
I have a main table and a lot of details tables that reference the
main one.
Every time I delete a record from the main table, a check is done on
every details table
On 1 December 2014 at 17:21, Giuseppe Sacco
giuse...@eppesuigoccas.homedns.org wrote:
Il giorno lun, 01/12/2014 alle 09.49 -0600, Andy Colson ha scritto:
On 12/1/2014 9:23 AM, Giuseppe Sacco wrote:
2) Try inheritance. I have no idea if it'll help, but I thought I'd
read someplace where the
On 12/1/2014 10:21 AM, Giuseppe Sacco wrote:
Il giorno lun, 01/12/2014 alle 09.49 -0600, Andy Colson ha scritto:
On 12/1/2014 9:23 AM, Giuseppe Sacco wrote:
Hello,
I have a main table and a lot of details tables that reference the
main one.
Every time I delete a record from the main table, a
On 12/1/2014 10:37 AM, Alban Hertroys wrote:
On 1 December 2014 at 17:21, Giuseppe Sacco
giuse...@eppesuigoccas.homedns.org wrote:
Il giorno lun, 01/12/2014 alle 09.49 -0600, Andy Colson ha scritto:
On 12/1/2014 9:23 AM, Giuseppe Sacco wrote:
2) Try inheritance. I have no idea if it'll
On Mon, 01 Dec 2014 11:00:51 -0600
Andy Colson a...@squeakycode.net wrote:
On 12/1/2014 10:21 AM, Giuseppe Sacco wrote:
Il giorno lun, 01/12/2014 alle 09.49 -0600, Andy Colson ha scritto:
On 12/1/2014 9:23 AM, Giuseppe Sacco wrote:
Hello,
I have a main table and a lot of details tables
Hi,
I have a rather complex set of relations, connected with cascading
foreign keys on delete. I'm experiencing very slow performance when
deleting *the* lead node, which everything eventually depends on. The
number of records ultimately to be deleted aren't that many (perhaps
2000-3000) but
Matthias Karlsson [EMAIL PROTECTED] writes:
I have a rather complex set of relations, connected with cascading
foreign keys on delete. I'm experiencing very slow performance when
deleting *the* lead node, which everything eventually depends on. The
number of records ultimately to be deleted
Tom Lane skrev:
Matthias Karlsson [EMAIL PROTECTED] writes:
I have a rather complex set of relations, connected with cascading
foreign keys on delete. I'm experiencing very slow performance when
deleting *the* lead node, which everything eventually depends on. The
number of records ultimately
Matthias Karlsson [EMAIL PROTECTED] writes:
Tom Lane skrev:
If it's a reasonably modern PG version, EXPLAIN ANALYZE will break out
the time spent in each on-delete trigger, which should be enough to
answer the question.
Thanks, that gave me something to work with. I targeted the triggers
Sorry. I realize this is a rather newbie question, but I've got a slow
delete going on here, and I could use some help figuring out why. This
is the classic get rid of orphans select.
delete from citizen where id not in (select citizenid from
citizen_stage);
citizen.id and
Doug Hall [EMAIL PROTECTED] writes:
delete from citizen where id not in (select citizenid from
citizen_stage);
The explain select tells me that there is a sequential select of
citizen_stage records. (??) There are 75009 citizen records and 14778
records, and it's taking more than half an
On Jul 13, 2005, at 12:46 PM, Tom Lane wrote:
Doug Hall [EMAIL PROTECTED] writes:
delete from citizen where id not in (select citizenid from
citizen_stage);
The explain select tells me that there is a sequential select of
citizen_stage records. (??) There are 75009 citizen records and 14778
Doug Hall [EMAIL PROTECTED] writes:
If the EXPLAIN output doesn't say
anything about a hashed subplan, then either you've got an old
version or there's some sort of estimation problem.
No, the EXPLAIN doesn't mention hashed subplan. I suspect it was a
bug in the beta.
You might need to
15 matches
Mail list logo
