| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Pavan Deolasee <pavan(dot)deolasee(at)2ndquadrant(dot)com> |
| Subject: | Re: rewrite HeapSatisfiesHOTAndKey |
| Date: | 2017-01-04 18:38:17 |
| Message-ID: | 20170104183817.sq4icaqhb25cgydl@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Pavan Deolasee wrote:
> A transaction then updates the second column in the table. So the
> refactored patch will do heap_getattr() on more columns that the master
> while checking if HOT update is possible and before giving up.
Thanks.
> 1-client
> Master Refactored
> Run1 8774.089935 8979.068604
> Run2 8509.2661 8943.613575
> Run3 8879.484019 8950.994425
>
>
> 8-clients
> Master Refactored
> Run1 22520.422448 22672.798871
> Run2 21967.812303 22022.969747
> Run3 22305.073223 21909.945623
Wow, this is very surprising. I was expecting a slight performance
decrease, not this. I will try to reproduce these numbers.
One thing worth mentioning is that the current implementation is not
very good -- I just kept the attribute check loop as it was in the
original, which uses heap_getattr. If we used incremental extraction
such as what we do in slot_getattr, it could be made a bit faster too.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-01-04 18:41:46 | Re: An isolation test for SERIALIZABLE READ ONLY DEFERRABLE |
| Previous Message | Robert Haas | 2017-01-04 18:26:08 | Re: Declarative partitioning - another take |