Re: Performance degradation in commit ac1d794

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Performance degradation in commit ac1d794
Дата
Msg-id 20160316185210.d3lymbovlch4htaw@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Performance degradation in commit ac1d794  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Performance degradation in commit ac1d794  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2016-01-14 12:07:23 -0500, Robert Haas wrote:
> On Thu, Jan 14, 2016 at 12:06 PM, Andres Freund <andres@anarazel.de> wrote:
> > On 2016-01-14 11:31:03 -0500, Robert Haas wrote:
> >> On Thu, Jan 14, 2016 at 10:56 AM, Andres Freund <andres@anarazel.de> wrote:
> >> I think your idea of a data structure the encapsulates a set of events
> >> for which to wait is probably a good one.  WaitLatch doesn't seem like
> >> a great name.  Maybe WaitEventSet, and then we can have
> >> WaitLatch(&latch) and WaitEvents(&eventset).
> >
> > Hm, I'd like to have latch in the name. It seems far from improbably to
> > have another wait data structure. LatchEventSet maybe? The wait would be
> > implied by WaitLatch.
> 
> I can live with that.


How about the following sketch of an API

typedef struct LatchEvent
{uint32 events; /* interesting events */uint32 revents;  /* returned events */int fd; /* fd associated with event */
} LatchEvent;

typedef struct LatchEventSet
{int nevents;LatchEvent events[FLEXIBLE_ARRAY_MEMBER];
} LatchEventSet;

/** Create a LatchEventSet with space for nevents different events to wait for.** latch may be NULL.*/
extern LatchEventSet *CreateLatchEventSet(int nevents, Latch *latch);

/* ---* Add an event to the set. Possible events are:* - WL_LATCH_SET: Wait for the latch to be set* -
WL_SOCKET_READABLE:Wait for socket to become readable*   can be combined in one event with WL_SOCKET_WRITEABLE* -
WL_SOCKET_WRITABLE:Wait for socket to become readable*   can be combined with WL_SOCKET_READABLE* -
WL_POSTMASTER_DEATH:Wait for postmaster to die*/
 
extern void AddLatchEventToSet(LatchEventSet *set, uint32 events, int fd);

/** Wait for any events added to the set to happen, or until the timeout is* reached.** The return value is the union
ofall the events that were detected. This* allows to avoid having to look into the associated events[i].revents*
fields.*/
extern uint32 WaitLatchEventSet(LatchEventSet *set, long timeout);



I've two questions:
- Is there any benefit of being able to wait for more than one latch? I'm inclined to not allow that for now, that'd
makethe patch bigger, and I don't see a use-case right now.
 
- Given current users we don't need a large amount of events, so having to iterate through the registered events
doesn'tseem bothersome. We could however change the api to be something like  int WaitLatchEventSet(LatchEventSet *set,
OccurredEvents*, int nevents, long timeout);
 
 which would return the number of events that happened, and would basically "fill" one of the (usually stack allocated)
OccurredEventstructures with what happened.
 


Comments?



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: WIP: Upper planner pathification
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Performance degradation in commit ac1d794