Re: Patching for increasing the number of columns

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Patching for increasing the number of columns
Дата
Msg-id 25156.1408555042@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Patching for increasing the number of columns  (Mayeul Kauffmann <mayeul.kauffmann@free.fr>)
Ответы Re: Patching for increasing the number of columns  (Mayeul Kauffmann <mayeul.kauffmann@free.fr>)
Список pgsql-hackers
Mayeul Kauffmann <mayeul.kauffmann@free.fr> writes:
> Tom wrote:
>> You would have to show us the actual failure diffs to get much useful 
>> comment, but in general increasing the size of tuple headers could 
>> easily lead to changes in plan choices

> Thank you Tom. So there is some hope! In effect the query plan is 
> different for the join and the view tests. The result set is different 
> only for the 'without_oid' test.

Hm.  I think the without_oid test is not showing that anything is broken;
what it's testing is whether a table with oids is physically bigger (more
pages) than one without oids but the same data.  It's not implausible
that your change results in the same number of tuples fitting onto a page
in both cases.  It'd be worth doing the math to make sure that makes
sense.  Not sure if there's an easy way to change the table schema so that
you get different physical sizes in both cases.

The other tests aren't showing any functional issue either AFAICS.
The change away from a nestloop plan in join.out is a bit annoying,
because IIRC that test is specifically intended to check nestloop
parameter management; but that just means the test is brittle.

> A side question: Are these tests comprehensive, or should I run other 
> tests just to be sure? Hints on where to find those tests are welcome.

No, they're not comprehensive, and no, we don't have more :-(
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: After switching primary server while using replication slot.
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: failures on barnacle (CLOBBER_CACHE_RECURSIVELY) because of memory leaks