Re: [HACKERS] 64-bit hashjoins

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] 64-bit hashjoins
Дата
Msg-id 27282.922319576@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] 64-bit hashjoins  (Erik Riedel <riedel+@CMU.EDU>)
Ответы Re: [HACKERS] 64-bit hashjoins  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] 64-bit hashjoins  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список pgsql-hackers
Erik Riedel <riedel+@CMU.EDU> writes:
>    1 elog(fmt = 0x1400067b0 = "create index: type for attribute '%s'
> undefined") ["elog.c":224, 0x12016e530]
>    2 NormIndexAttrs(attList = 0x8fc, attNumP = 0x1401e91e2, classOidP =
> 0x1401e91f8) ["indexcmds.c":500, 0x12007ae5c]

> Does this help identify where to look?

Just from looking at that chunk of the source, it seems that the problem
is in either pg_type or pg_attribute, since it is using a field from a
pg_attribute tuple to look for a pg_type tuple... probably
pg_attribute... which starts out with   Oid         attrelid;   NameData    attname;   Oid         atttypid;
Could it be NameData?  A few minutes later: YUP!

>From pg_type, type "name" is declared as having fixed length 32 and
int-alignment (typalign = 'i').  This is dubious enough, since a
compiler is likely to treat a char array as having only byte alignment;
typalign = 'c' seems more correct.  But it's been working so far and
prolly wouldn't break on an Alpha.

But in src/include/access/tupmacs.h we find the code that actually
implements attribute alignment calculations, and it reads:

#define att_align(cur_offset, attlen, attalign) \
( \   ((attlen) < sizeof(int32)) ? \   ( \       ((attlen) == -1) ? \       ( \           ((attalign) == 'd') ?
DOUBLEALIGN(cur_offset): \                                   INTALIGN(cur_offset) \       ) \       : \       ( \
   ((attlen) == sizeof(char)) ? \           ( \               (long)(cur_offset) \           ) \           : \
( \               AssertMacro((attlen) == sizeof(short)), \               SHORTALIGN(cur_offset) \           ) \
)\   ) \   : \   ( \       ((attlen) == sizeof(int32)) ? \       ( \           INTALIGN(cur_offset) \       ) \       :
\      ( \           AssertMacro((attlen) > sizeof(int32)), \           ((attalign) == 'd') ?   DOUBLEALIGN(cur_offset)
:\                                   LONGALIGN(cur_offset) \       ) \   ) \
 
)

Walk through that with attlen = 32, attalign = 'i', and guess what:
it applies LONGALIGN().  Which is different on Alpha than everywhere
else, not to mention flat-out wrong for the given arguments.

Erik, try changing that last LONGALIGN to INTALIGN and see if it
works any better on the Alpha.

We probably really ought to bag this entire logic and replace it
with something like    attalign 'c' -> no alignment    attalign 's' -> SHORTALIGN    attalign 'i' -> INTALIGN
attalign'd' -> DOUBLEALIGN
 
with possibly some AssertMacro cross-checks that the given attlen
makes sense for the attalign.  But driving the logic primarily off
attlen rather than attalign makes little sense to me.
        regards, tom lane


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

Предыдущее
От: RHS Linux User
Дата:
Сообщение: Re: [HACKERS] Really slow query on 6.4.2
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] static oid