jbrockmendel
jbrockmendel
@mvashishtha I understand copartitioning may occur. But _after_ co-partitioning, aren't the partition-by-partition operations shape-preserving? That's why im suggesting they be preserved in binary_operation, not in binary_op.
@YarShev i think you said you confirmed this optimization is correct but found it didn't make a huge difference in the use case you were profiling? worth making a PR?
> I think the to_pandas() call flushes out the queue so any lazy operations will get evaluated. is there a maximally-cheap way to do this?
> what do you mean by "maximally cheap"? is there a way to flush the queue that is cheaper than to_pandas?
I meant something to do inside Series._getitem to get the accurate results
So... what would be an edit to add to this PR in `Series._getitem` to get correct results?
in pandas if a PR includes _user-facing_ changes we ask the contributor to add a note in the appropriate whatsnew file. Not for e.g. refactoring or CLN PRs.
@anmyachev worth expanding on what this entails?
Looks like the to_pandas is happening on a query_compiler where qc._modin_frame has 1 column and 1 row, so we get a scalar back. This still gets a bunch of overhead...
just rebased. based on today's call i think everyone is on board?