From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Васильев Дмитрий <d(dot)vasilyev(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Performance degradation in commit ac1d794 |
Date: | 2016-03-17 15:17:49 |
Message-ID: | 20160317151749.7yvv4fsd5rfkqc3t@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016-03-17 09:01:36 -0400, Robert Haas wrote:
> > * Right now the caller has to allocate the WaitEvents he's waiting for
> > locally (likely on the stack), but we also could allocate them as part
> > of the WaitEventSet. Not sure if that'd be a benefit.
>
> I'm not seeing this. What do you mean?
Right now, do use a WaitEventSet you'd do something like
WaitEvent event;
ModifyWaitEvent(FeBeWaitSet, 0, waitfor, NULL);
WaitEventSetWait(FeBeWaitSet, 0 /* no timeout */, &event, 1);
i.e. use a WaitEvent on the stack to receive the changes. If you wanted
to get more changes than just one, you could end up allocating a fair
bit of stack space.
We could instead allocate the returned events as part of the event set,
and return them. Either by returning a NULL terminated array, or by
continuing to return the number of events as now, and additionally
return the event data structure via a pointer.
So the above would be
WaitEvent *events;
int nevents;
ModifyWaitEvent(FeBeWaitSet, 0, waitfor, NULL);
nevents = WaitEventSetWait(FeBeWaitSet, 0 /* no timeout */, events, 10);
for (int off = 0; off <= nevents; nevents++)
; // stuff
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2016-03-17 15:21:48 | Re: btree_gin and btree_gist for enums |
Previous Message | Teodor Sigaev | 2016-03-17 15:15:59 | Re: WIP: Access method extendability |