Move PG code out of filter logic #487
Conversation
| } | ||
|
|
||
| #include "pgduckdb/pgduckdb_filter.hpp" |
There was a problem hiding this comment.
I thought there were filters we can't push down?
There was a problem hiding this comment.
Yeah, but those we then also shouldn't receive from DuckDB. They should simply be executed by DuckDB.
There was a problem hiding this comment.
Ah yeah because everything will be emitted to DuckDB values after 477 lands. I think you're right. I'll keep this one on standby but will move to another file.
| bool DatumGetBool(Datum datum) { | ||
| return ::DatumGetBool(datum); | ||
| } |
There was a problem hiding this comment.
I'm kinda worried that for these tiny functions the call overhead of this could be significant. Postgres defines all these as static inline functions.
There was a problem hiding this comment.
To be clear, I'm thinking that maybe we should vendor in the required functions from Postgres in our own header instead.
There was a problem hiding this comment.
Yeah I was thinking the same - since we decided we didn't really care in a previous PR I went that way, but I was about to ping you exactly for that :-)
There was a problem hiding this comment.
Yeah, for some other places I wasn't too worried. But these seem like they're likely to be used in the hot-path. Still even the indirection might be fine there.
No description provided.