| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
| Cc: | "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: like/ilike improvements |
| Date: | 2007-09-21 10:00:31 |
| Message-ID: | 87k5qkuym8.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
"ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
> "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com> wrote:
>
>> It's better but still slower than 8.2.
>
> It probablly comes from 'var-varlena' feature in 8.3. Now we store
> text fields in a compact format on disks and extract them on access.
> It consumes some CPU cycles. If all of data are in buffer cache
> and the encoding of database is single-byte encodings, the performance
> of LIKE in 8.3 was 10-20% slower than 8.2 on my tests.
Hm, it does seem I missed like.c when I converted all the text operators to
avoid detoasting packed varlenas. I'll send a patch in a few minutes to do
that. I'm surprised it would have such a large effect though.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2007-09-21 10:24:43 | Re: Improving the Performance of Full Table Updates |
| Previous Message | Heikki Linnakangas | 2007-09-21 09:47:48 | Re: Beginning Tamil Community for Postgre |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Meskes | 2007-09-21 10:45:18 | Re: ecpg PREPARE is not thread safe |
| Previous Message | ITAGAKI Takahiro | 2007-09-21 09:41:38 | Re: like/ilike improvements |