From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: POC: converting Lists into arrays |
Date: | 2019-03-02 23:11:43 |
Message-ID: | 24783.1551568303@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Here's a v3 incorporating Andres' idea of trying to avoid a separate
palloc for the list cell array. In a 64-bit machine we can have up
to five ListCells in the initial allocation without actually increasing
space consumption at all compared to the old code. So only when a List
grows larger than that do we need more than one palloc.
I'm still having considerable difficulty convincing myself that this
is enough of a win to justify the bug hazards we'll introduce, though.
On test cases like "pg_bench -S" it seems to be pretty much within the
noise level of being the same speed as HEAD. I did see a nice improvement
in the test case described in
https://www.postgresql.org/message-id/6970.1545327857@sss.pgh.pa.us
but considering that that's still mostly a tight loop in
match_eclasses_to_foreign_key_col, it doesn't seem very interesting
as an overall figure of merit.
I wonder what test cases Andres has been looking at that convince
him that we need a reimplementation of Lists.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
reimplement-List-as-array-3.patch.gz | application/x-gzip | 45.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-03-02 23:48:30 | Re: Online verification of checksums |
Previous Message | Tom Lane | 2019-03-02 22:29:49 | Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's |