Re: [RFC] ASOF Join
От | Alexander Kuzmenkov |
---|---|
Тема | Re: [RFC] ASOF Join |
Дата | |
Msg-id | 1cbd7c0d-5998-c63c-db33-f5516897176c@timescale.com обсуждение исходный текст |
Ответ на | Re: [RFC] ASOF Join (Ilya Anfimov <ilan@tzirechnoy.com>) |
Ответы |
Re: [RFC] ASOF Join
|
Список | pgsql-hackers |
On 21.11.2021 07:53, Ilya Anfimov wrote: > DISCLAIMER: I am both seeing this first time and I don't have a > good understanding of the PosgreSQL development practices. > pure evil > ridiculous No worries, at least you got the etiquette just right. There are two points in your mail that I'd like to discuss. First, the ASOF grammar being bad because it's implicit. I doagree on the general idea that explicit is better UX than implicit, especially when we're talking about SQL where you spendhalf the time battling the query planner already. However, in the grammar I proposed it's unambiguous which conditionsare ASOF and which are not -- all inequalities are ASOF, all equalities are not, and there can be no other kindsof conditions for this type of join. It can also support any number of ASOF conditions. Which grammar exactly do yousuggest? Maybe something like this: asks JOIN bids ON asks.instrument = bids.instrument ASOF asks.timestamp <= bids.timestamp This still does require a keyword. Second, you say that we must first optimize the corresponding LATERAL. I was thinking about this as well, but _that_ is what'snot explicit. I'm not sure if this optimization would have any value outside of optimizing ASOF joins. We might givebetter UX if we embrace the fact that we're doing an ASOF join and allow the user to state this explicitly and get anefficient and predictable plan, or an error, instead of trying to guess this from the rewritten queries and silently fallingback to an inefficient plan for cryptic reasons. -- Alexander Kuzmenkov Timescale
В списке pgsql-hackers по дате отправления: