DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=ZSk0ZGi4GwwS2gG4x7cxKgmwMwRE6HHOLsJ4ULyK2EDZPF0QSpRy5epJ8LPlfgO4jKsGFUVBIhZsJV6AH7xemX1WFhNm1g6v3kiPuRryy9GMzkhQ9aGXRN4zb+mCdjmTvu2Usg4v2ZQnnFzkhlvrqx3uQH+1RB5RtmuFlVclAXw=
Message-ID: <1d4e0c10711070538mf773791ke5950849299b142c@mail.gmail.com>
Date: Wed, 7 Nov 2007 14:38:04 +0100
From: "Guillaume Smet" <guillaume.smet@gmail.com>
To: "Alexander Staubo" <alex@purefiction.net>
Subject: Re: Estimation problem with a LIKE clause containing a /
Cc: pgsql-performance <pgsql-performance@postgresql.org>
In-Reply-To: <88daf38c0711070525r1e7d6daft56970045de0ec8f4@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1d4e0c10711070453q214f089cpd144cbb5193d3c4f@mail.gmail.com>
	<88daf38c0711070525r1e7d6daft56970045de0ec8f4@mail.gmail.com>

Alexander,

On 11/7/07, Alexander Staubo <alex@purefiction.net> wrote:
> That's a difference of less than *three milliseconds* -- a difference
> probably way within the expected overhead of running "explain
> analyze". Furthermore, all three queries use the same basic plan: a
> sequential scan with a filter. At any rate you're microbenchmarking in
> a way that is not useful to real-world queries. In what way are these
> timings a problem?

If you read my previous email carefully, you'll see they aren't a
problem: the problem is the estimation, not the timing. This is a self
contained test case of a far more complex query which uses a bad plan
containing a nested loop due to the bad estimate.

> Now all "like 'prefix%'" queries should use the index.

Not when you retrieve 50% of this table of 22k rows but that's not my
problem anyway. A seqscan is perfectly fine in this case.

Thanks anyway.

--
Guillaume