From: Carlo Stonebanks <stonec.register@sympatico.ca>
To: pgsql-performance@postgresql.org
Subject: Re: Performace Optimization for Dummies
Date: Thu, 28 Sep 2006 15:10:49 -0400
Message-ID: <efh6nt$11k4$1@news.hub.org> (raw)
References: <efgu4v$276m$1@news.hub.org>
<b42b73150609281017m7f8f9d86xfa32d38cec954af7@mail.gmail.com>
<efh26m$2fd$1@news.hub.org>
<5EE4B6D1-8ECE-4033-A912-DFD9146A5A93@blighty.com>
> Are you wrapping all this in a transaction?
Yes, the transactions can typically wrap 1 to 10 single-table, single-row
inserts and updates.
> You're doing some dynamically generated selects as part of the
> "de-duping" process? They're probably the expensive bit. What
> do those queries tend to look like?
Without a doubt, this is the expensive bit.
> Are you analysing the table periodically? If not, then you might
> have statistics based on an empty table, or default statistics, which
> might cause the planner to choose bad plans for those selects.
Now there's something I didn't know - I thought that analysis and planning
was done with every select, and the performance benefit of prepared
statements was to plan-once, execute many. I can easily put in a periodic
analyse statement. I obviously missed how to use analyze properluy, I
thought it was just human-readable output - do I understand correctly, that
it can be used to get the SQL server to revaluate its plan based on newer
statistics - even on non-prepared queries?
> Talking of which, are there indexes on the table? Normally you
> wouldn't have indexes in place during a bulk import, but if you're
> doing selects as part of the data load process then you'd be forcing
> sequential scans for every query, which would explain why it gets
> slower as the table gets bigger.
There are indexes for every obvious "where this = that" clauses. I don't
believe that they will work for ilike expressions.
>
> Cheers,
> Steve
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: stonec.register@sympatico.ca
Subject: Re: Performace Optimization for Dummies
In-Reply-To: <efh6nt$11k4$1@news.hub.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox