Re: Or selection on index versus union

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: han(dot)holl(at)informationslogik(dot)nl
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Or selection on index versus union
Date: 2005-10-05 22:31:17
Message-ID: 20051005223117.GI40138@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Oct 05, 2005 at 11:13:58AM +0200, han(dot)holl(at)informationslogik(dot)nl wrote:
> On Tuesday 04 October 2005 23:08, Michael Fuhr wrote:
> > On Tue, Oct 04, 2005 at 09:32:41PM +0200, han(dot)holl(at)informationslogik(dot)nl wrote:
> > > I've got a table with an index, let's call it fase.
> > >
> > > The following query is fine: 'select something from table where fase =
> > > '1';
> > >
> > > However, this is disastrously slow:
> > > select something from table where fase = '1' or fase = '2';
> >
> > Could we see some EXPLAIN ANALYZE output? What version of PostgreSQL
> > are you using? Have you run VACUUM ANALYZE on the table to remove
> > dead tuples and update the statistics? Have you considered clustering
> > the table on fase's index?
> >
>
> Oh, well, thanks. I hadn't realized that a newly loaded database needs a vacuum analyze to begin with. And what's worse, I had the impression that vacuum full would include analyze, wich I see now it doesn't.

When first loaded, there are no statistics for a table, so the database
has no idea what to expect. You don't need to vacuum a brand-new table,
but you do need to analyze it.

We've actually talked about changing the name of vacuum full so as not
to confuse people. But you really want to stay away from vacuum full
unless you have no choice, because of the exclusive lock on the table it
grabs.

> I'm not a database administrator, and I'm afraid it shows. I'm going to read a lot of docs in the coming months, because real people depend on reasonable performance of our databases.

If you need immediate help you can get commercial support from a number
of companies.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Browse pgsql-general by date

  From Date Subject
Next Message OpenMacNews 2005-10-05 22:34:13 portable pgsql binary/pkg building on OSX ...
Previous Message Adam Lawrence 2005-10-05 22:30:53 Trying to append text to the end of a text string