From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: POC: converting Lists into arrays |
Date: | 2019-06-14 02:32:23 |
Message-ID: | 898.1560479543@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> On Fri, 14 Jun 2019 at 13:54, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> Have you tested the performance impact?
> I did some and posted earlier in the thread:
> https://postgr.es/m/CAKJS1f8h2vs8M0cgFsgfivfkjvudU5-MZO1gJB2uf0m8_9VCpQ@mail.gmail.com
> It came out only slightly slower over the whole regression test run,
> which I now think is surprisingly good considering how much we've
> tuned the code over the years with the assumption that List is a
> singly linked list. We'll be able to get rid of things like
> PlannerInfo's simple_rte_array and append_rel_array along with
> EState's es_range_table_array.
Yeah. I have not made any attempt at all in the current patch to
re-tune the code, or clean up places that are maintaining parallel
Lists and arrays (such as the ones David mentions). So it's not
entirely fair to take the current state of the patch as representative
of where performance would settle once we've bought into the new
method.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2019-06-14 02:53:36 | Re: release notes: tids & self-joins |
Previous Message | Bruce Momjian | 2019-06-14 02:08:20 | Re: vacuumdb as server application in v12 release note |