Re: [HACKERS] [POC] hash partitioning
От | Ashutosh Bapat |
---|---|
Тема | Re: [HACKERS] [POC] hash partitioning |
Дата | |
Msg-id | CAFjFpRdDtHR0cheCR5Z-cKWiYB6Wu0fP4gYvpizR2bMKvB_1uw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [POC] hash partitioning (amul sul <sulamul@gmail.com>) |
Ответы |
Re: [HACKERS] [POC] hash partitioning
|
Список | pgsql-hackers |
On Tue, Oct 10, 2017 at 4:37 PM, amul sul <sulamul@gmail.com> wrote: > On Tue, Oct 10, 2017 at 3:42 PM, Ashutosh Bapat > <ashutosh.bapat@enterprisedb.com> wrote: >> On Tue, Oct 10, 2017 at 3:32 PM, amul sul <sulamul@gmail.com> wrote: >> >>>> + hash_part? true : key->parttypbyval[j], >>>> + key->parttyplen[j]); >>>> parttyplen is the length of partition key attribute, whereas what you want here >>>> is the length of type of modulus and remainder. Is that correct? Probably we >>>> need some special handling wherever parttyplen and parttypbyval is used e.g. in >>>> call to partition_bounds_equal() from build_joinrel_partition_info(). >>>> >>> >>> Unless I am missing something, I don't think we should worry about parttyplen >>> because in the datumCopy() when the datatype is pass-by-value then typelen >>> is ignored. >> >> That's true, but it's ugly, passing typbyvalue of one type and len of other. >> > > How about the attached patch(0003)? > Also, the dim variable is renamed to natts. Probably we should move changes to partition_bounds_copy() in 0003 to 0001, whose name suggests so. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: