From: mark@mark.mielke.cc
To: 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: Thu, 24 May 2007 17:54:51 -0400
Message-ID: <20070524215450.GA3858@mark.mielke.cc> (raw)
In-Reply-To: <1180040560.31471.262.camel@archimedes>
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>
On Thu, May 24, 2007 at 02:02:40PM -0700, Mark Lewis wrote:
> PG could scan the index looking for matches first and only load the
> actual rows if it found a match, but that could only be a possible win
> if there were very few matches, because the difference in cost between a
> full index scan and a sequential scan would need to be greater than the
> cost of randomly fetching all of the matching data rows from the table
> to look up the visibility information.
> So yes it would be possible, but the odds of it being faster than a
> sequential scan are small enough to make it not very useful.
> And since it's basically impossible to know the selectivity of this kind
> of where condition, I doubt the planner would ever realistically want to
> choose that plan anyway because of its poor worst-case behavior.
What is a real life example where an intelligent and researched
database application would issue a like or ilike query as their
primary condition in a situation where they expected very high
selectivity?
Avoiding a poor worst-case behaviour for a worst-case behaviour that
won't happen doesn't seem practical.
What real life examples, that could not be implemented a better way,
would behave poorly if like/ilike looked at the index first to filter?
I don't understand... :-)
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, 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: <20070524215450.GA3858@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