Re: [PERFORM] REVISIT specific query (not all) on Pg8 MUCH slower than Pg7

Hello again - vacuum analyze of db did the trick, thanks! longer procedure went from over 6 hours to ~11 minutesquite dramatic. Reindexing wasn't necessary (did test on one db -slog-slog-, though). Regards, Susan >From [EMAIL PROTECTED] Thu May 10 09:47:38 2007 X-Spam-Checker-Version: SpamA

Re: [PERFORM] Background vacuum

Dan Harris wrote: > Daniel Haensse wrote: >> Has anybody a nice >> solution to change process priority? A shell script, maybe even for java? One way is to write astored procedure that sets it's own priority. An example is here: http://weblog.bignerdranch.com/?p=11 > While this may technically wo

Re: [PERFORM] Nested loops overpriced

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Am Mittwoch, 9. Mai 2007 19:40 schrieb Tom Lane: >> Hmmm ... I see at least part of the problem, which is that email_header >> is joined twice in this query, which means that it's counted twice in >> figuring the total volume of pages competing for cac

Re: [PERFORM] Nested loops overpriced

Am Mittwoch, 9. Mai 2007 19:40 schrieb Tom Lane: > Hmmm ... I see at least part of the problem, which is that email_header > is joined twice in this query, which means that it's counted twice in > figuring the total volume of pages competing for cache space.  So the > thing thinks cache space is ov

Re: [PERFORM] Nested loops overpriced

Am Mittwoch, 9. Mai 2007 19:40 schrieb Tom Lane: > I remember having dithered about whether > to try to avoid counting the same physical relation more than once in > total_table_pages, but this example certainly suggests that we > shouldn't. Meanwhile, do the estimates get better if you set > effe

Re: [PERFORM] REVISIT specific query (not all) on Pg8 MUCH slower than Pg7

>Quick reminders: >*) Did you recreate all the indexes on the new system after the initdb? >*) Did you vacuum and analyze after loading your data? No, I didn't - am reindexing db now and will run vacuum analyze afterwards. >I suggest you provide "explain analyze" output for the query o

Re: [PERFORM] REVISIT specific query (not all) on Pg8 MUCH slower than Pg7

In response to Susan Russo <[EMAIL PROTECTED]>: > > > Hi again, > > Very mixed news to report... > > Recap: > > > I'd reported: > > Despite numerous efforts, we're unable to solve a severe performance > >limitation between Pg 7.3.2 > > and Pg 8.1.4. > > > > The query and 'explain analyze' p

Re: [PERFORM] REVISIT specific query (not all) on Pg8 MUCH slower than Pg7

On Thu, May 10, 2007 at 09:23:03AM -0400, Susan Russo wrote: > my $aq = $dbh->prepare(sprintf("SELECT * from dbxref dx, db where > accession = '%s' and dx.db_id = db.db_id and db.name = 'GB_protein'",$rec)); This is not related to your performance issues, but it usually considered bad form

[PERFORM] REVISIT specific query (not all) on Pg8 MUCH slower than Pg7

Hi again, Very mixed news to report... Recap: I'd reported: > Despite numerous efforts, we're unable to solve a severe performance >limitation between Pg 7.3.2 > and Pg 8.1.4. > > The query and 'explain analyze' plan below, runs in > 26.20 msec on Pg 7.3.2, and > 2463.968 ms on

Re: [PERFORM] Cannot make GIN intarray index be used by the planner

Hello again, I got the opclass for the index and it looks like it is a default one myvideoindex=# select pg_opclass.*, pg_type.typname myvideoindex-# from pg_index, pg_opclass, pg_type myvideoindex-# where pg_index.indexrelid = 'idx_nonnulls_myintarray_int4_gin'::regclass myvideoindex-#an