Re: [PERFORM] A query become very slow after upgrade from 8.1.10 to 8.4.5

2010-11-02 Thread Yaocl
On Wed, Nov 3, 2010 at 6:30 AM, Tom Lane wrote: > Yaocl writes: >> SELECT t_a.id FROM t_a >> WHERE EXISTS ( SELECT t_b.id FROM t_b, t_c >>                WHERE t_b.id = t_a.id AND t_c.flag = 'f') > > I have some hopes for fixing this in 9.1, but nothing is going to happen > in 8.4 or 9.0.  In the

Re: [PERFORM] Array interface

2010-11-02 Thread Conor Walsh
On Tue, Nov 2, 2010 at 2:32 PM, Mladen Gogala wrote: > I was surprised because I expected array bind to produce better > results over the network than the row-by-row operations, yet it > didn't. Can anybody elaborate a bit? While all of the bulk-execute functions are likely to have implementatio

Re: [PERFORM] A query become very slow after upgrade from 8.1.10 to 8.4.5

2010-11-02 Thread Tom Lane
Yaocl writes: > SELECT t_a.id FROM t_a > WHERE EXISTS ( SELECT t_b.id FROM t_b, t_c >WHERE t_b.id = t_a.id AND t_c.flag = 'f') I have some hopes for fixing this in 9.1, but nothing is going to happen in 8.4 or 9.0. In the meantime, is it intentional that there is no join clause b

[PERFORM] Array interface

2010-11-02 Thread Mladen Gogala
I sent 2 emails, both containing a Perl code sample, but none of them went through. Essentially, I was testing Perl array bind & execute. Everything went well, except for the fact that array execute is no faster than the row-by-row way of executing things. I was surprised because I expected arr

[PERFORM] Test

2010-11-02 Thread Mladen Gogala
Can you hear me now? -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscrip

Re: [PERFORM] Insert performance with composite index

2010-11-02 Thread Cédric Villemain
2010/11/2 hubert depesz lubaczewski : > On Tue, Nov 02, 2010 at 12:04:42PM +0100, Cédric Villemain wrote: >> 2010/11/2 hubert depesz lubaczewski : >> > On Mon, Nov 01, 2010 at 02:57:56PM +0100, Cédric Villemain wrote: >> >> >   CONSTRAINT tableindex_pkey PRIMARY KEY (tableindex) >> >> > ) >> >> > t

Re: [PERFORM] Insert performance with composite index

2010-11-02 Thread Divakar Singh
May be a query that is filtering based on these 2 columns? Best Regards, Divakar From: Cédric Villemain To: dep...@depesz.com Cc: Divakar Singh ; pgsql-performance@postgresql.org Sent: Tue, November 2, 2010 4:34:42 PM Subject: Re: [PERFORM] Insert performance

Re: [PERFORM] Insert performance with composite index

2010-11-02 Thread hubert depesz lubaczewski
On Tue, Nov 02, 2010 at 12:04:42PM +0100, Cédric Villemain wrote: > 2010/11/2 hubert depesz lubaczewski : > > On Mon, Nov 01, 2010 at 02:57:56PM +0100, Cédric Villemain wrote: > >> >   CONSTRAINT tableindex_pkey PRIMARY KEY (tableindex) > >> > ) > >> > the index definition is > >> > CREATE INDEX "P

Re: [PERFORM] Insert performance with composite index

2010-11-02 Thread Cédric Villemain
2010/11/2 hubert depesz lubaczewski : > On Mon, Nov 01, 2010 at 02:57:56PM +0100, Cédric Villemain wrote: >> >   CONSTRAINT tableindex_pkey PRIMARY KEY (tableindex) >> > ) >> > the index definition is >> > CREATE INDEX "PK_AT2" >> >   ON ABC >> >   USING btree >> >   (event, tableindex) >> > TABLES

Re: [PERFORM] Insert performance with composite index

2010-11-02 Thread hubert depesz lubaczewski
On Mon, Nov 01, 2010 at 02:57:56PM +0100, Cédric Villemain wrote: > >   CONSTRAINT tableindex_pkey PRIMARY KEY (tableindex) > > ) > > the index definition is > > CREATE INDEX "PK_AT2" > >   ON ABC > >   USING btree > >   (event, tableindex) > > TABLESPACE sample; > > Indexing twice the same column