Так-то когда права есть, всё хорошо)

за день управишься )

А когда нужно вотпрямщас, получается пип инсталл в юдф)

Привет, столкнулся с таким поведением спарка: есть колонка с пропусками в датафрейме, хочу её фильтрануть по условию !=2, смотрю результат: у меня дропнулись строчки не только с двойками но и с пропусками. Если фильтровать по ==2, то остаются строчки только с 2 (что логично). Баг это или фича?
Что именно меня смущает: как мне кажется, такое поведение не соответствует логике - есть закон в булевой алгебре, что x + !x =1, а тут получается, что df.filter(myCondition) и df.filter(!myCondition) при объединении не дают первоначальный датасет

Может не правильно понял твою ситуацию, почему просто не добавить условие || col is null?

Если значения колонок null, то можно говорить, что null не в полной мере соответствует формальной логике, ибо «0 это присутствие отсутствия, а null это отсутствие присутсвия»

Конкретно эту ситуацию обойти можно)
Вопрос про то, что насколько логично такое поведение: при фильтрации != abc удалять и строки с пропусками

Ты в принципе не можешь сравнивать null, ибо null != null, аналогично и любое другое сравнение null с другими значениями.

Вообще я видимо не в ту степь тебя веду.
Если я не путаюсь то ты опираешься на формальную(двузначную логику), понятие null, оно же unknown по сути относится к троичной логике. Там немного другие правила

Есть вот такое правило, касаемо СУБД:
Правила операций с UNKNOWN
Любая операция сравнения любого значения с NULL или UNKNOWN даёт в результате UNKNOWN.
not UNKNOWN = UNKNOWN
TRUE and UNKNOWN = UNKNOWN
FALSE and UNKNOWN = FALSE
TRUE or UNKNOWN = TRUE
FALSE or UNKNOWN = UNKNOWN
TRUE xor UNKNOWN = UNKNOWN
FALSE xor UNKNOWN = UNKNOWN

Спасибо, стало понятнее

есть nullsafe =!=

Ну и
Null <=> null есть True

Вот это трешово довольно.

А это как переводится на примитивный русский?

Если с обеих сторон не налл или с обеих сторон налл, то труе. Иначе фалсе.

А, данке шон

In order to compare the NULL values for equality, Spark provides a null-safe equal operator (‘<=>’), which returns False when one of the operand is NULL and returns ‘True when both the operands are NULL.

Ребята, могли бы подсказать, есть ли опасность(с точки зрения производительности) установления слишком большого fetchSize при записе/чтении jdbc?

Обычно использую 10 тыс, но возникает вопрос почему бы не 100?
Играют ли роль размера кэша rom СУБД, при котором после достижения некого размера пакета(batch’а) сами диски не смогут обеспечить нужную скорость записи?

100к оптимально. Можно ещё Воркеров увеличить в постгре и под такое же кол-во параллельности записи добавить.