On Mon, 01 Dec 2014 11:00:51 -0600
Andy Colson 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 that r
On 12/1/2014 10:37 AM, Alban Hertroys wrote:
On 1 December 2014 at 17:21, 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:
2) Try inheritance. I have no idea if it'll help, but I thought I'd
read someplace
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 1 December 2014 at 17:21, 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:
>> 2) Try inheritance. I have no idea if it'll help, but I thought I'd
>> read someplace where the planner knew a little more ab
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
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:
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 numer
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 tri
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 ultimatel
"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 del
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 there
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 mig
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 1477
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 ha
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 citizen_stage.ci
15 matches
Mail list logo
