Composite multicolumn index for geopoint range and numeric range query
@jjanes' answer on stackoverflow that I accepted

With the help of the btree_gist extension, you can include the
event_type and start_date columns into the GiST index along with the
event_position.  However, the event_type won't be very useful in the
index as long as the restriction clause is something like event_type in (0, 1, 2).  (But if the list only contains one element, it will be
rewritten into an equality, and in that case it can use that column in
the index efficiently.)  So using the other two columns would be my
starting point.  I would put the usually more selective one first.  If
you are going to leave past events in the table rather than clearing
them out, then the date is probably going to eventually be the more
selective one.
If the location condition is not very selective at all (e.g. most of
your events are in NYC, and most of your users are in NYC, and almost
everything is within 100km of almost everything else), then you might
want a different approach.  Just make a default BTREE index on
(event_type, start_date).  Unlike GiST, such a BTREE can effectively
use a condition like event_type in (0, 1, 2) along with AND start_date between x and y.
I don't think that there is a fundamental reason GiST can't use the
in-list effectively while BTREE can.  Maybe that will be fixed for
GiST in some future version.