Re: [HACKERS] Surjective functional indexes
От | Konstantin Knizhnik |
---|---|
Тема | Re: [HACKERS] Surjective functional indexes |
Дата | |
Msg-id | 40fd1ef1-6227-69d1-9a24-edfef875e006@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] Surjective functional indexes (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: [HACKERS] Surjective functional indexes
Re: [HACKERS] Surjective functional indexes Re: [HACKERS] Surjective functional indexes Re: [HACKERS] Surjective functional indexes Re: [HACKERS] Surjective functional indexes |
Список | pgsql-hackers |
On 07.01.2018 01:59, Stephen Frost wrote: > Greetings, > > * Konstantin Knizhnik (k.knizhnik@postgrespro.ru) wrote: >> On 15.12.2017 01:21, Michael Paquier wrote: >>> On Fri, Dec 15, 2017 at 6:15 AM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: >>>> Konstantin Knizhnik wrote: >>>>> If you still thing that additional 16 bytes per relation in statistic is too >>>>> high overhead, then I will also remove autotune. >>>> I think it's pretty clear that these additional bytes are excessive. >>> The bar to add new fields in PgStat_TableCounts in very high, and one >>> attempt to tackle its scaling problems with many relations is here by >>> Horiguchi-san: >>> https://www.postgresql.org/message-id/20171211.201523.24172046.horiguchi.kyotaro@lab.ntt.co.jp >>> His patch may be worth a look if you need more fields for your >>> feature. So it seems to me that the patch as currently presented has >>> close to zero chance to be committed as long as you keep your changes >>> to pgstat.c. >> Ok, looks like everybody think that autotune based on statistic is bad idea. >> Attached please find patch without autotune. > This patch appears to apply with a reasonable amount of fuzz, builds, > and passes 'make check', at least, therefore I'm going to mark it > 'Needs Review'. > > I will note that the documentation doesn't currently build due to this: > > /home/sfrost/git/pg/dev/cleanup/doc/src/sgml/ref/create_index.sgml:302: parser error : Opening and ending tag mismatch:literal line 302 and unparseable > <term><literal>recheck_on_update</></term> > > but I don't think it makes sense for that to stand in the way of someone > doing a review of the base patch. Still, please do fix the > documentation build when you get a chance. > > Thanks! > > Stephen Sorry, issue with documentation is fixed. -- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Вложения
В списке pgsql-hackers по дате отправления: