Re: NOT LIKE much faster than LIKE?

Поиск
Список
Период
Сортировка
Искать
От
Matteo Beccati
Тема
Re: NOT LIKE much faster than LIKE?
Дата
Msg-id
43C3799D.5030103@beccati.com
Ответ на
Список
Дерево обсуждения
NOT LIKE much faster than LIKE? Andrea Arcangeli <andrea@cpushare.com>
Re: NOT LIKE much faster than LIKE? "Jim C. Nasby" <jnasby@pervasive.com>
Re: NOT LIKE much faster than LIKE? Andrea Arcangeli <andrea@cpushare.com>
Re: NOT LIKE much faster than LIKE? Andrea Arcangeli <andrea@cpushare.com>
Re: NOT LIKE much faster than LIKE? "Jim C. Nasby" <jnasby@pervasive.com>
Re: NOT LIKE much faster than LIKE? Tom Lane <tgl@sss.pgh.pa.us>
Re: NOT LIKE much faster than LIKE? Tom Lane <tgl@sss.pgh.pa.us>
Re: NOT LIKE much faster than LIKE? Andrea Arcangeli <andrea@cpushare.com>
Re: NOT LIKE much faster than LIKE? Stephan Szabo <sszabo@megazone.bigpanda.com>
Re: NOT LIKE much faster than LIKE? Tom Lane <tgl@sss.pgh.pa.us>
Re: NOT LIKE much faster than LIKE? Andrea Arcangeli <andrea@cpushare.com>
Re: NOT LIKE much faster than LIKE? Greg Stark <gsstark@mit.edu>
Re: NOT LIKE much faster than LIKE? Andrea Arcangeli <andrea@cpushare.com>
Re: NOT LIKE much faster than LIKE? Tom Lane <tgl@sss.pgh.pa.us>
Re: NOT LIKE much faster than LIKE? Andrea Arcangeli <andrea@cpushare.com>
Re: NOT LIKE much faster than LIKE? Matteo Beccati <php@beccati.com>
Re: NOT LIKE much faster than LIKE? Tom Lane <tgl@sss.pgh.pa.us>
Re: NOT LIKE much faster than LIKE? Simon Riggs <simon@2ndquadrant.com>
Re: NOT LIKE much faster than LIKE? Tom Lane <tgl@sss.pgh.pa.us>
Re: NOT LIKE much faster than LIKE? Simon Riggs <simon@2ndquadrant.com>
Re: NOT LIKE much faster than LIKE? Tom Lane <tgl@sss.pgh.pa.us>
Re: NOT LIKE much faster than LIKE? Simon Riggs <simon@2ndquadrant.com>
Re: NOT LIKE much faster than LIKE? Andrea Arcangeli <andrea@cpushare.com>
Re: NOT LIKE much faster than LIKE? Simon Riggs <simon@2ndquadrant.com>
Re: NOT LIKE much faster than LIKE? Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: NOT LIKE much faster than LIKE? Andrea Arcangeli <andrea@cpushare.com>
Hi,

> I did just think of something we could improve though.  The pattern
> selectivity code doesn't make any use of the statistics about "most
> common values".  For a constant pattern, we could actually apply the
> pattern test with each common value and derive answers that are exact
> for the portion of the population represented by the most-common-values
> list.  If the MCV list covers a large fraction of the population then
> this would be a big leg up in accuracy.  Dunno if that applies to your
> particular case or not, but it seems worth doing ...

This reminds me what I did in a patch which is currently on hold for the 
next release:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold
http://candle.pha.pa.us/mhonarc/patches_hold/msg00026.html

The patch was addressing a similar issue when using ltree <@ and @> 
operator on an unbalanced tree.


Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
В списке pgsql-performance по дате отправления
От: Alessandro Baretta
Дата:
От: Ron
Дата:
FAQ