From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: ArrayLists instead of List (for some things) |
Date: | 2017-11-02 14:53:50 |
Message-ID: | 30137.1509634430@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:
>> It seems to me that a whole lot of the complaints about this could be
>> resolved simply by improving the List infrastructure to allocate ListCells
>> in batches. That would address the question of "too much palloc traffic"
>> and greatly improve the it-accesses-all-over-memory situation too.
>>
>> Possibly there are more aggressive changes that could be implemented
>> without breaking too many places, but I think it would be useful to
>> start there and see what it buys us.
> Yeah, certainly would be a good way of determining the worth of changing.
BTW, with just a little more work that could be made to address the
list-nth-is-expensive problem too. I'm imagining a call that preallocates
an empty list with room for N ListCells (or perhaps, if we need to
preserve compatibility with NIL == NULL, creates a single-element list
with room for N-1 more cells), plus some tracking in list.c of whether
the list cells have been consumed in order. Given the typical use-case of
building lists strictly with lappend, list_nth() could index directly into
the ListCell slab as long as it saw the List header's "is_linear" flag was
true.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2017-11-02 14:55:25 | Re: [HACKERS] pgsql: Fix freezing of a dead HOT-updated tuple |
Previous Message | David Rowley | 2017-11-02 14:46:03 | Re: ArrayLists instead of List (for some things) |