Re: [PERFORM] plain inserts and deletes very slow

* David Mitchell <[EMAIL PROTECTED]> wrote: Hi, > Hmm, you said you don't experience this when executing the query > manually. What adapter are you using to access postgres from your > application? libpq, npgsql or something else? huh, its a delphi application ... (I didnt code it). > And wh

Re: [PERFORM] plain inserts and deletes very slow

* Alvaro Herrera <[EMAIL PROTECTED]> wrote: > On Mon, Jul 04, 2005 at 02:17:47AM +0200, Enrico Weigelt wrote: > > * David Mitchell <[EMAIL PROTECTED]> wrote: > > > Perhaps if you are doing a lot of inserts and deletes, vacuuming every 6 > > > minutes would be closer to your mark. Try vacuuming eve

Re: [PERFORM] plain inserts and deletes very slow

On Mon, Jul 04, 2005 at 10:57:29AM +0200, Enrico Weigelt wrote: > * Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > On Mon, Jul 04, 2005 at 02:17:47AM +0200, Enrico Weigelt wrote: > > > * David Mitchell <[EMAIL PROTECTED]> wrote: > > > > Perhaps if you are doing a lot of inserts and deletes, vacuumin

[PERFORM] Why the planner is not using the INDEX .

Hi all,   If you can just help my understanding the choice of the planner.  Here is the Query:  explain analyse SELECT IRNUM FROM IR     INNER JOIN IT ON  IT.ITIRNUM = ANY ('{1000, 2000}') AND IT.ITYPNUM = 'M' AND IR.IRYPNUM = IT.ITYPNUM AND IR.IRNUM = IT.ITIRNUM      WHERE IRNUM =

Re: [PERFORM] Why the planner is not using the INDEX .

On Mon, 4 Jul 2005, David Gagnon wrote: > If you can just help my understanding the choice of the planner. > > Here is the Query: > explain analyse SELECT IRNUM FROM IR > INNER JOIN IT ON IT.ITIRNUM = ANY ('{1000, 2000}') AND > IT.ITYPNUM = 'M' AND IR.IRYPNUM = IT.ITYPNUM AND IR.IRNUM

Re: [PERFORM] plain inserts and deletes very slow

On Mon, 4 Jul 2005 10:59:03 +0200, Enrico Weigelt <[EMAIL PROTECTED]> wrote: > * David Mitchell <[EMAIL PROTECTED]> wrote: > > Hi, > > > Hmm, you said you don't experience this when executing the query > > manually. What adapter are you using to access postgres from your > > application? libpq,

Re: [PERFORM] Why the planner is not using the INDEX .

Thanks .. I miss that FK don't create indexed ...  since Primary key implicitly does ... I'm a bit surprised of that behavior thought, since it means that if we delete a row from table A all tables (B,C,D) with FK pointing to this table (A) must be scanned.  If there is no index on those tabl

Re: [PERFORM] Why the planner is not using the INDEX .

I'm a bit surprised of that behavior thought, since it means that if we delete a row from table A all tables (B,C,D) with FK pointing to this table (A) must be scanned. If there is no index on those tables it means we gone do all Sequantial scans. Than can cause significant performance problem!