On Dec 9, 2008, at 3:27 PM, Tom Lane wrote:
Richard Yen [EMAIL PROTECTED] writes:
I've discovered a peculiarity with using btrim in an index and was
wondering if anyone has any input.
What PG version is this?
This is running on 8.3.3
In particular, I'm wondering if it's one of the early
Richard Yen [EMAIL PROTECTED] writes:
You guys are right. I tried Miller and gave me the same result. Is
there any way to tune this so that for the common last names, the
query run time doesn't jump from 1s to 300s?
If the planner's estimation is that far off then there must be something
You guys are right. I tried Miller and gave me the same result. Is there
any way to tune this so that for the common last names, the query run time
doesn't jump from 1s to 300s?
Thanks for the help!
Can you send the output of EXPLAIN ANALYZE for both cases?
...Robert
--
Sent via
BTW, if your queries typically constrain both lastname and firstname,
it'd likely be worthwhile to make a 2-column index on
lower(btrim(x_lastname)), lower(btrim(x_firstname))
regards, tom lane
--
Sent via pgsql-performance mailing list
On Dec 10, 2008, at 11:34 AM, Tom Lane wrote:
Richard Yen [EMAIL PROTECTED] writes:
You guys are right. I tried Miller and gave me the same result.
Is
there any way to tune this so that for the common last names, the
query run time doesn't jump from 1s to 300s?
If the planner's
On Dec 10, 2008, at 11:39 AM, Robert Haas wrote:
You guys are right. I tried Miller and gave me the same result.
Is there
any way to tune this so that for the common last names, the query
run time
doesn't jump from 1s to 300s?
Thanks for the help!
Can you send the output of EXPLAIN
tii=# explain analyze SELECT m_object_paper.id FROM m_object_paper,
m_assignment WHERE m_object_paper.assignment = m_assignment.id AND
m_object_paper.owner=-1 AND m_assignment.class = 2450798 AND
lower(btrim(x_firstname)) = lower(btrim('Jordan')) and
lower(btrim(x_lastname)) =
Richard Yen [EMAIL PROTECTED] writes:
Is there any way to tune this so that for the common last names, the query
run time doesn't jump from 1s to 300s?
Well, as near as I can tell there's factor of a couple hundred
difference between the frequencies of 'smith' and 'smithers', so
you shouldn't
On Dec 10, 2008, at 4:08 PM, Tom Lane wrote:
Richard Yen [EMAIL PROTECTED] writes:
Is there any way to tune this so that for the common last names,
the query
run time doesn't jump from 1s to 300s?
Well, as near as I can tell there's factor of a couple hundred
difference between the
Hi,
I've discovered a peculiarity with using btrim in an index and was
wondering if anyone has any input.
My table is like this:
Table public.m_object_paper
Column| Type | Modifiers
On Tue, Dec 9, 2008 at 2:56 PM, Richard Yen [EMAIL PROTECTED] wrote:
In practice, the difference is 300+ seconds when $LASTNAME == 5 chars and 1
second when $LASTNAME != 5 chars.
Would anyone know what's going on here? Is there something about the way
btrim works, or perhaps with the way
Richard Yen [EMAIL PROTECTED] writes:
I've discovered a peculiarity with using btrim in an index and was
wondering if anyone has any input.
What PG version is this?
In particular, I'm wondering if it's one of the early 8.2.x releases,
which had some bugs in and around choose_bitmap_and()
12 matches
Mail list logo
