Re: NOT LIKE much faster than LIKE?
От
Matteo Beccati
Тема
Re: NOT LIKE much faster than LIKE?
Дата
Msg-id
43C3799D.5030103@beccati.com
Ответ на
Re: NOT LIKE much faster than LIKE? (Tom Lane)
Список
Дерево обсуждения
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 по дате отправления