Re: Solving the OID-collision problem
От | Mark Woodward |
---|---|
Тема | Re: Solving the OID-collision problem |
Дата | |
Msg-id | 22592.24.91.171.78.1123176841.squirrel@mail.mohawksoft.com обсуждение исходный текст |
Ответ на | Re: Solving the OID-collision problem (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> "Mark Woodward" <pgsql@mohawksoft.com> writes: >>> I'm too lazy to run an experiment, but I believe it would. Datum is >>> involved in almost every function-call API in the backend. In >>> particular this means that it would affect performance-critical code >>> paths. > >> I hear you on the "lazy" part, but if OID becomes a structure, then you >> are still comparing a native type until you get a match, then you make >> one >> more comparison to confirm it is the right one, or move on. > > No, you're missing the point entirely: on 32-bit architectures, passing > a 32-bit integral type to a function is an extremely well optimized > operation, as is returning a 32-bit integral type. Passing or > returning a 64-bit struct is, um, not so well optimized. That's only if you call by value, call by reference is just as optimized. > > There's also the small problem that it really has to fit into Datum. > Would it break a lot if you add more to a datum?
В списке pgsql-hackers по дате отправления: