From: mark@mark.mielke.cc
To: Richard Huxton <dev@archonet.com>
Cc: Mark Lewis <mark.lewis@mir3.com>
Cc: James Mansion <james@mansionfamily.plus.com>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: Alexander Staubo <alex@purefiction.net>
Cc: Andy <frum@ar-sd.net>
Cc: pgsql-performance@postgresql.org
Subject: Re: LIKE search and performance
Date: Fri, 25 May 2007 12:56:33 -0400
Message-ID: <20070525165633.GA13579@mark.mielke.cc> (raw)
In-Reply-To: <4657023A.20209@archonet.com>
References: <009501c79d4c$445428f0$0b00a8c0@mpsro.dom>
<88daf38c0705230905u1a981102k691b47bd36011a80@mail.gmail.com>
<4655DE75.4080506@mansionfamily.plus.com>
<4655E64B.5050503@hagander.net>
<4655FB8A.1040707@mansionfamily.plus.com>
<1180040560.31471.262.camel@archimedes>
<20070524215450.GA3858@mark.mielke.cc>
<46569AA5.10205@archonet.com>
<20070525141630.GA12162@mark.mielke.cc>
<4657023A.20209@archonet.com>
On Fri, May 25, 2007 at 04:35:22PM +0100, Richard Huxton wrote:
> >I notice you did not provide a real life example as requested. :-)
> OK - any application that allows user-built queries: <choose column:
> foo> <choose filter: contains> <choose target: "bar">
> Want another? Any application that has a "search by name" box - users
> can (and do) put one letter in and hit enter.
> Unfortunately you don't always have control over the selectivity of
> queries issued.
The database has 10 million records. The user enters "bar" and it
translates to "%bar%". You are suggesting that we expect bar to match
1 million+ records? :-)
I hope not. I would define this as bad process. I would also use "LIMIT"
to something like "100".
> >This seems like an ivory tower restriction. Not allowing best performance
> >in a common situation vs not allowing worst performance in a not-so-common
> >situation.
> What best performance plan are you thinking of? I'm assuming we're
> talking about trailing-wildcard matches here, rather than "contains"
> style matches.
"Trailing-wildcard" already uses B-Tree index, does it not?
I am speaking of contains, as contains is the one that was said to
require a seqscan. I am questioning why it requires a seqscan. The
claim was made that with MVCC, the index is insufficient to check
for visibility and that the table would need to be accessed anyways,
therefore a seqscan is required. I question whether a like '%bar%'
should be considered a high selectivity query in the general case.
I question whether a worst case should be assumed.
Perhaps I question too much? :-)
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
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: mark@mark.mielke.cc, dev@archonet.com, mark.lewis@mir3.com, james@mansionfamily.plus.com, magnus@hagander.net, alex@purefiction.net, frum@ar-sd.net
Subject: Re: LIKE search and performance
In-Reply-To: <20070525165633.GA13579@mark.mielke.cc>
* 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