from customer - Maybe MDEV-15214 isnt fixed for Columnstore tables

2) It can be something else but IMHO it relates to that JIRA ticket in some way. The query was an UPDATE. It was stuck on UM level. I saw those queries in the process list on UM1 with that status as I put in the issue description when I logged this ticket. While stuck on UM1 it never made it to PM level as I checked for locks on the system and it came clean with “no locks detected on the system” message. So that is why I think it might be related even not completely 100% the same.
3) This is a though one. Let me think about it and I will try to do something with our demo data on a separate (and somehow isolated) dataset. The problem with this whole TEST is that at certain point when this hit the first time UM SQL interface stopped being responsive. It did not hose entire host but It indeed looked scary and I did not want to poke around much as I did not know what to expect. One thing is when you try to bring system back to somehow usable state and the other is when it works fine and you are about to try something that may (and most probably will) mess it up. I did not grow that much of braveness in me yet.

customer will try to come up with a specific test case.. They do believe its related to:

Long story short - our UPDATE is using IN condition in WHERE clause on the varchar(40) field with multiple loooong strings in it. This is completely wrong approach from the programmer point of view and we will have to fix this but that argument aside - if I will be able to conclusively confirm that this is the case I will describe in very detail how to reproduce this behavior.

They asked:

I need to know at least what to avoid while we are going to wait for the fix in the database engine level.

Hi,

it's really a showstopper.
We have the sam problem with tables having almost varchar(100) columns (1.2.5 GA on centos 7, big single server system with billions of rows at all and some hundred GB of RAM, not running in swap or to the end of cache or disc, no other workload on server during my tests). Some SQL die on "init for update" while no visible action ist shown in "top". Tables are mostly new (temp) tables having a lot of updates and inserts before problem coming up. The problem does not depend on IN statements here (same with equal operator). I found out that it will always happen when the table include some million rows (aprox 8 an greater). Same if not used rows are already deleted. After building a new table form old without not necessary rows (approx. 10% result size) same SQL works within seconds (maybe an important circumstance in terms of optimizing). Btw. this Problem was coming up to my attention with newer Columnstore Version (after 1.6).
If it depend on settings, which specific settings should be good to solve the issue?

The SQL (all Columns varchar(100)):
update TABLE_NAME set A_=B_, C_= 'ebce9ca200808aae58', B_old=A_outputID, A_outputID= '1' , F_=B_
where C_='ebce8c096c69bd') and A_outputID = '0' and E_ in ('Z123');

The SQL is working more than one times with A_outputID, this could be a potential reason? But it works with a new, smaller table and no syntax error is never coming up...

Thanks a lot in advance.

This ticket was opened prior to convergence with the server. It may have been rendered obsolete. If this issue still exists in a modern version, please open a new request.