Re: Collect frequency statistics for arrays
От | Robert Haas |
---|---|
Тема | Re: Collect frequency statistics for arrays |
Дата | |
Msg-id | CA+Tgmob1zxaLKOuuD9wUygVAneG_ePPjA8pzhOD8s29O=xfZ6A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Collect frequency statistics for arrays (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Collect frequency statistics for arrays
|
Список | pgsql-hackers |
On Wed, Feb 29, 2012 at 5:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Nathan Boley <npboley@gmail.com> writes: >> On Wed, Feb 29, 2012 at 12:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> I am starting to look at this patch now. I'm wondering exactly why the >>> decision was made to continue storing btree-style statistics for arrays, >>> in addition to the new stuff. > >> If I understand you're suggestion, queries of the form > >> SELECT * FROM rel >> WHERE ARRAY[ 1,2,3,4 ] <= x >> AND x <=ARRAY[ 1, 2, 3, 1000]; > >> would no longer use an index. Is that correct? > > No, just that we'd no longer have statistics relevant to that, and would > have to fall back on default selectivity assumptions. Do you think that > such applications are so common as to justify bloating pg_statistic for > everybody that uses arrays? I confess I am nervous about ripping this out. I am pretty sure we will get complaints about it. Performance optimizations that benefit group A at the expense of group B are always iffy, and I'm not sure the case of using an array as a path indicator is as uncommon as you seem to think. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: