From: | James Mansion <james(at)mansionfamily(dot)plus(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Alexander Staubo <alex(at)purefiction(dot)net>, Andy <frum(at)ar-sd(dot)net>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: LIKE search and performance |
Date: | 2007-05-24 20:54:34 |
Message-ID: | 4655FB8A.1040707@mansionfamily.plus.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> If Sybase is still like SQL Server (or the other way around), it *may*
> end up scanning the index *IFF* the index is a clustered index. If it's
> a normal index, it will do a sequential scan on the table.
>
>
Are you sure its not covered? Have to check at work - but I'm off next
week so it'll have to wait.
> It's not a win on PostgreSQL, because of our MVCC implementation. We
> need to scan *both* index *and* data pages if we go down that route, in
> which case it's a lot faster to just scan the data pages alone.
>
>
Why do you need to go to all the data pages - doesn't the index
structure contain all the keys so
you prefilter and then check to see if the *matched* items are still in
view? I'll be first to admit I
know zip about Postgres, but it seems odd - doesn't the index contain
copies of the key values?.
I suspect that I mis-spoke with 'leaf'. I really just mean 'all index
pages with data', since the scan
does not even need to be in index order, just a good way to get at the
data in a compact way.
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Lewis | 2007-05-24 21:02:40 | Re: LIKE search and performance |
Previous Message | Magnus Hagander | 2007-05-24 19:23:55 | Re: LIKE search and performance |