Re: speedup COPY TO for partitioned table.
От | jian he |
---|---|
Тема | Re: speedup COPY TO for partitioned table. |
Дата | |
Msg-id | CACJufxEOM4sOP8m7fLd3upy=KX90021nrjmtJ5Fr9Of030GQuQ@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: speedup COPY TO for partitioned table.
|
Список | pgsql-hackers |
On Wed, Jan 22, 2025 at 6:54 AM Melih Mutlu <m.melihmutlu@gmail.com> wrote: > > Hi Jian, > > Thanks for the patch. > > jian he <jian.universality@gmail.com>, 19 Ara 2024 Per, 15:03 tarihinde şunu yazdı: >> >> attached copy_par_regress_test.sql is a simple benchmark sql file, >> a partitioned table with 10 partitions, 2 levels of indirection. >> The simple benchmark shows around 7.7% improvement in my local environment. > > > I confirm that the patch introduces some improvement in simple cases like the one you shared. I looked around a bit tounderstand whether there is an obvious reason why copying from a partitioned table is not allowed, but couldn't find one.It seems ok to me. hi. melih mutlu thanks for confirmation. > I realized that while both "COPY <partitioned_table> TO..." and "COPY (SELECT..) TO..." can return the same set of rows,their orders may not be the same. I guess that it's hard to guess in which order find_all_inheritors() would returntables, and that might be something we should be worried about with the patch. What do you think? > in the find_all_inheritors->find_inheritance_children->find_inheritance_children_extended find_inheritance_children_extended we have """ if (numoids > 1) qsort(oidarr, numoids, sizeof(Oid), oid_cmp); """ so the find_all_inheritors output order is deterministic?
В списке pgsql-hackers по дате отправления: