Re: Deferring some AtStart* allocations?
От | Andres Freund |
---|---|
Тема | Re: Deferring some AtStart* allocations? |
Дата | |
Msg-id | 20140630012207.GI21422@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Deferring some AtStart* allocations? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2014-06-29 21:12:49 -0400, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > On 2014-06-29 19:52:23 -0400, Tom Lane wrote: > >> Andres Freund <andres@2ndquadrant.com> writes: > >>> Why aren't we delaying allocations in e.g. AtStart_Inval(), > >>> AfterTriggerBeginXact() to when the data structures are acutally used? > >> > >> Aren't we? Neither of those would be doing much work certainly. > > > They are perhaps not doing much in absolute terms, but it's a fair share > > of the processing overhead for simple statements. AfterTriggerBeginXact() > > is called unconditionally from StartTransaction() and does three > > MemoryContextAlloc()s. AtStart_Inval() one. > > I think they should just be initialized whenever the memory is used? > > Doesn't look too complicated to me. > > Meh. Even "SELECT 1" is going to be doing *far* more pallocs than that to > get through raw parsing, parse analysis, planning, and execution > startup. The quick test I ran used prepared statements - there the number of memory allocations is *much* lower... > If you can find a few hundred pallocs we can avoid in trivial queries, > it would get interesting; but I'll be astonished if saving 4 is measurable. I only noticed it because it shows up in profiles. I doubt it'll even remotely be noticeable without using prepared statements, but a lot of people do use those. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: