You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In our system, external tables are used as a means of
moving subsets of data from the server to remote
clients. The external table is accessed on the client
side and merged into their full set of data.
Currently, I can't zip up the created external
tables/files until the external tables are dropped. The
drop process (for all tables) takes a finite set of
time around 1 minute. It would be very helpful if the
drop process was optimized or the file locks could be
avoided so I could zip the file and do the cleanup after.
-Mark E.
The text was updated successfully, but these errors were encountered:
It may have to do with some of the tables being
exceptionally wide. One of the tables has 296 fields.
Vlad, I will send a table definition to your email.
I'm unable to reproduce significant delays when dropping 100
external tables. My times is near 1.3 sec on execute 100
DROP TABLE statements (non autocommit) and near 0.5
sec for COMMIT after it.
Submitted by: mericksen (mericksen)
SFID: 1020512#
Submitted By: mericksen
In our system, external tables are used as a means of
moving subsets of data from the server to remote
clients. The external table is accessed on the client
side and merged into their full set of data.
Currently, I can't zip up the created external
tables/files until the external tables are dropped. The
drop process (for all tables) takes a finite set of
time around 1 minute. It would be very helpful if the
drop process was optimized or the file locks could be
avoided so I could zip the file and do the cleanup after.
-Mark E.
The text was updated successfully, but these errors were encountered: