One bad thing that I lose indexing and other info that monetdb gathered during my queries previously. Anyways, probably deletes and updates were anyway marking those dirty and candidates for recalculations?
Regards, Manish
On Sun, Mar 26, 2017 at 5:11 PM, Manish gupta gahoimnshg@gmail.com wrote:
Thanks, let me try it.
I hope, the suggestion is this
sql>insert into t2 ( id, name ) select id, name from t1; 2 affected rows (121.998ms) sql>drop t1;
Regards, Manish
On Sun, Mar 26, 2017 at 3:11 PM, Stefan Manegold Stefan.Manegold@cwi.nl wrote:
Being a database system, MonetDB keeps persistent data on disk. Being a memory-optimized databse system, MonetDB tries to use as much memory as available to acheive high query processing performance. However, it should not "demand" more than available.
A binary copy of your table in MonetDB will be smaller (and faster) than serializing to text (CSV).
Stefan
----- On Mar 26, 2017, at 9:05 AM, Manish gupta gahoimnshg@gmail.com wrote:
Hi Ying, Thanks for response. Would not this method need 2 copies of same data
in DB at
the same time ( until original table is finally deleted fully )? Would
it
demand more memory, as my dataset is quite large.
Regards, Manish
On Sun, Mar 26, 2017 at 12:02 PM, Ying Zhang < Y.Zhang@cwi.nl > wrote:
On 26 Mar 2017, at 08:04, Manish gupta < gahoimnshg@gmail.com > wrote:
OK, I got there is no vacuum cleaning algo implemented yet. https://www.monetdb.org/Documentation/Manuals/SQLreference/
Transactions
Would drop the records after ascii dump and recreate table.
You can also temporarily store the data of the <table to be cleaned> in
a
<backup table>. Then do a “delete from <table to be cleaned>”, which simply wipe out
all data,
incl. garbage from <table to be cleaned>. Finally, put all data from <backup table> back to <table to be cleaned>.
This is mostly probably (much) faster than an ASCII dump and restore.
Regards, Manish
On Sat, Mar 25, 2017 at 5:25 PM, Manish gupta < gahoimnshg@gmail.com
wrote:
The problem is that I am having ~70M rows in a table, but its bat
storage size
is showing 170M rows. Although the count * still returns 70M, but
memory is
increasing very heavy each day. As described in previous mail, each
day, ~1M
rows are deleted from table and ~1.1M added, but it actually increases
the size
by 1.1M. Please let me know if something wrong in this way of updation of
monetDB tables.
Regards, manish
On Sat, Mar 25, 2017 at 2:05 PM, Manish gupta < gahoimnshg@gmail.com
wrote:
Dear All, Is there a way to truncate the table size when deleting some of the
records? In
my application, I delete and insert ~1 million records daily. But
effectively,
it should result in few hundreds additional records. But, I see the
size of the
table increases by a millions ( that can be seen in storage(), as well
as hard
disk size ). While the "select count(*) from table" reflects correct
number. Is
there a way, I can stop increase in table size in my scheme?
Regards, Manish
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
-- | Stefan.Manegold@CWI.nl | DB Architectures (DA) | | www.CWI.nl/~manegold/ | Science Park 123 (L321) | | +31 (0)20 592-4212 | 1098 XG Amsterdam (NL) | _______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list