Re: zheap: a new storage format for PostgreSQL
От | Mithun Cy |
---|---|
Тема | Re: zheap: a new storage format for PostgreSQL |
Дата | |
Msg-id | CAD__Ouguz4oSX6uQskU4Cm9AMcQgCmEDknpBPdKAKCKkiS3kjQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: zheap: a new storage format for PostgreSQL (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: zheap: a new storage format for PostgreSQL
|
Список | pgsql-hackers |
On Thu, Dec 6, 2018 at 11:13 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Thu, Dec 6, 2018 at 10:03 AM Pavel Stehule <pavel.stehule@gmail.com> wrote: > > > > čt 6. 12. 2018 v 5:02 odesílatel Mithun Cy <mithun.cy@enterprisedb.com> napsal: > >> > >> COPY command seems to have improved very slightly with zheap in both with size of wal and execution time. I also didsome tests with insert statement where I could see some regression in zheap when compared to heap with respect to executiontime. With further more investigation I will reply here. > >> > > > > 20% of size reduction looks like effect of fill factor. > > > > I think it is because of smaller zheap tuple sizes. Mithun can tell > more about setup whether he has used different fillfactor or anything > else which could lead to such a big difference. Yes default fillfactor is unaltered, zheap tuples sizes are less and alinged each at 2 Bytes Length of each item. (all Items are identical) ===================================== postgres=# SELECT lp_len FROM zheap_page_items(get_raw_page('pgbench_zheap', 9)) limit 1; lp_len -------- 102 (1 row) postgres=# SELECT lp_len FROM heap_page_items(get_raw_page('pgbench_heap', 9)) limit 1; lp_len -------- 121 (1 row) Total tuples per page ===================================== postgres=# SELECT count(*) FROM zheap_page_items(get_raw_page('pgbench_zheap', 9)); count ------- 76 (1 row) postgres=# SELECT count(*) FROM heap_page_items(get_raw_page('pgbench_heap', 9)); count ------- 61 (1 row) because of this zheap takes less space as reported above. -- Thanks and Regards Mithun Chicklore Yogendra EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: