Re: Advices on custom data type and extension development

Поиск
Список
Период
Сортировка
От Corey Huinker
Тема Re: Advices on custom data type and extension development
Дата
Msg-id CADkLM=e=nVVkDoWRgq-d6SJGw2Qj5_b-cPthyWRhCG5jOJynbA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Advices on custom data type and extension development  (Kevin Grittner <kgrittn@gmail.com>)
Список pgsql-hackers
Дерево обсуждения
Seriously, you should consider having a primary key with two
columns, of type date and int.  It would take exactly the same
space as your current plan, and performance should be very close to
what you propose.  As long as you aren't using some ORM that is too
dumb to deal with this, it should be far easier than creating the
custom type.

+1 

Most ORMs cannot handle ENUMs, let alone user defined composite types.

That, or they flood the database with SELECT * FROM pg_type WHERE ... queries. I'm looking at you, Cake.

You're far better off trying a (date,integer) key as Kevin said.

If the ORM doesn't allow that, I'd suggest a custom function that encodes the date bit-shifted to the high 4 bytes, and then adds in the four bytes from a cycling sequence. At least then you've got a shot at partitioning, though the lower/upper bounds of the partitions would not make sense to the casual observer.

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: PATCH: postpone building buckets to the end of Hash (in HashJoin)
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Advices on custom data type and extension development