users-list December 2011

users-list@monetdb.org

13 participants
17 discussions

[MonetDB-users] MonetDB JDBC 1.9 question

by Charalampos Nikolaou

Hi, I am getting some strange exceptions using MonetDB JDBC 1.8/1.9, and I decided to look into the code. While inspecting the code I came across these strange lines in MonetConnection.executeQuery(String[] templ, String query) method (http://dev.monetdb.org/hg/MonetDB/file/718da8ca0a1a/java/src/nl/cwi/monetdb…). In my case, these lines are executed for sure when doing a batch insert. So, suppose that the batch contains the following commands (as constructed by the MonetStatement.executeBatch() method): exec 1(1, 957339737330229055); exec 1(2, 278262503670654331); exec 1(805306369, 3763943296910752235) The lines in question take the above commands as a string, prepend a 's' character and append a ';' at the end. The resulting commands, which are written in the server's socket, are the following: sexec 1(1, 957339737330229055); exec 1(2, 278262503670654331); exec 1(805306369, 3763943296910752235); First of all, I am not familiar with the internals of JDBC drivers. Taking this into account, is this what it should be? From a symmetric point of view, I would assume that the correct would be the following: sexec 1(1, 957339737330229055); sexec 1(2, 278262503670654331); sexec 1(805306369, 3763943296910752235); That is, it should prepend a 's' character before an exec command. Last, are these exec commands (with or without a prepending 's') specific to MonetDB? In either case, is there any documentation to get familiar with their meaning? Thanks a lot, Babis

10 years, 5 months

[MonetDB-users] Strange disk I/O behavior

by Viktor Rosenfeld

Hi, I'm observing disk I/O when evaluating some queries which I am unable to explain. I have two datasets, one relatively small with the BATs taking up 1.6 MB on disk and one fairly large with 283 MB on disk. According to iostat, when I evaluate the attached query on the small dataset, 100 MB are written to disk, but none are read. This is on a Linux machine with 4 GB RAM running the Aug2011-SP3 release. I don't understand why data is written on disk, that (a) is never read again and (b) would easily fit into main memory. I am unable to evaluate the queries on the large dataset because MonetDB writes so much data that the disk fills up after a few minutes (more than 22GB). Please let me know if I can provide more information. Cheers, Viktor

10 years, 6 months

[MonetDB-users] column sortedness

by David Pennell

I'm running some experiments with a 1B row fact table (10 columns). - How can I tell if a column is sorted? - If I generate files in sorted order and use binary bulk loading, will monetdb consider the column sorted? If not, can I force it? I've been reading code, but understanding all the assignments to bn->tsorted is going to take a while. I get the general theme of setting tsorted during bat operations, but I've been unsuccessful in finding where it is initialized when a column is first accessed. TIA, -david

10 years, 6 months

[MonetDB-users] ENUM style table with JOIN versus automatically deduplicated VARCHAR

by Stefan de Konink

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, MonetDB 'deduplicates' strings, is there any benchmark that outlines the performance difference of an ENUM with a low number of (string)items versus the use of a VARCHAR field? The technical question would be; Is it more efficient to do: select * from my_table, my_enum where mytable.my_enum_id = my_enum.id and my_enum.name = 'Something'; or select * from my_table where my_enum_varchar = 'something'; I can imagine that the following would out perform a string comparison, but implies hardcoded values. select * from my_table, my_enum where mytable.my_enum_id = hardcoded; Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk78fnkACgkQYH1+F2Rqwn3BUQCeOUtPIGzcHT1xpnsF4n78BQ/1 JWAAnjnzPeT8D7CtsjYgAiGg/WRIgNbQ =989f -----END PGP SIGNATURE-----

10 years, 6 months

[MonetDB-users] MonetDB internals, does UPDATE update in place?

by Stefan de Konink

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Just to be very sure; I know that the DELETE, INSERT strategy to update the database will guarantee a database that keeps on growing, because of the lack of VACUUM. Is the normal UPDATE statement for fixed width datatypes in place, or is it also a form of copy-on-write? Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAk78fPwACgkQYH1+F2Rqwn2fxACfWdXvwr4pWODNo4ZH9uq5oVS9 BmwAn16XGh8h/vYsGkvthKej3MA8Nyvi =KK5T -----END PGP SIGNATURE-----

10 years, 7 months

[MonetDB-users] Maximum size for SQL command in mclient

by Charalampos Nikolaou

Hi, is there a maximum size for an SQL command (e.g., INSERT INTO statement) that is imposed in mclient? The connection is terminated when I execute several commands from a sql file one of which is quite long. The point where I get the error is at the 8192th byte (which is the last of 8KBs). Babis

10 years, 7 months

[MonetDB-users] protocol violation: unexpected line in data block

by tangray

the whole log file : RD 1298855541531: read final block: 57 bytes RX 1298855541531: onxRWd3Yv:mserver:9:RIPEMD160,SHA256,SHA1,MD5:LIT:SHA512: RD 1298855541531: inserting prompt TD 1298855541531: write final block: 92 bytes TX 1298855541531: BIG:risk:{SHA256}01fa94fefcadb5918473e49aaa8e425538f8d40960b2d649348cb17c599031ae:sql:krisk: RD 1298855541546: read final block: 0 bytes RX 1298855541546: RD 1298855541546: inserting prompt TD 1298855541546: write final block: 48 bytes TX 1298855541546: sSET TIME ZONE INTERVAL '+08:00' HOUR TO MINUTE; RD 1298855541546: read final block: 0 bytes RX 1298855541546: RD 1298855541546: inserting prompt TD 1298855541546: write final block: 15 bytes TX 1298855541546: Xreply_size 250 RD 1298855541546: read final block: 0 bytes RX 1298855541546: RD 1298855541546: inserting prompt TD 1298855541546: write final block: 46 bytes TX 1298855541546: sSELECT "name", "value" FROM sys.env() as env; RD 1298855541546: read final block: 4246 bytes RX 1298855541546: &1 0 46 2 46 % .env, .env # table_name % name, value # name % varchar, varchar # type % 18, 203 # length [ "gdk_arch", "32biti686-pc-win32" ] [ "gdk_version", "1.40.3" ] [ "prefix", "D:\\Program Files\\MonetDB\\MonetDB5" ] [ "exec_prefix", "D:\\Program Files\\MonetDB\\MonetDB5" ] [ "gdk_dbname", "krisk" ] [ "gdk_dbfarm", "C:\\Documents and Settings\\swordtan\\Application Data\\MonetDB5\\dbfarm" ] [ "gdk_debug", "0" ] [ "gdk_alloc_map", "no" ] [ "gdk_vmtrim", "yes" ] [ "monet_admin", "adm" ] [ "monet_prompt", ">" ] [ "monet_welcome", "yes" ] [ "monet_mod_path", "D:\\Program Files\\MonetDB\\MonetDB5\\lib\\MonetDB5;D:\\Program Files\\MonetDB\\MonetDB5\\lib\\MonetDB5\\lib;D:\\Program Files\\MonetDB\\MonetDB5\\lib\\MonetDB5\\bin" ] [ "monet_daemon", "no" ] [ "host", "localhost" ] [ "mapi_port", "50000" ] [ "mapi_clients", "2" ] [ "mapi_open", "true" ] [ "mapi_autosense", "false" ] [ "default_pipe", "inline,remap,evaluate,costModel,coercions,emptySet,aliases,mitosis,mergetable,deadcode,commonTerms,joinPath,reorder,deadcode,reduce,dataflow,history,multiplex,garbageCollector" ] [ "minimal_pipe", "inline,remap,deadcode,multiplex,garbageCollector" ] [ "sql_optimizer", "default_pipe" ] [ "sql_debug", "0" ] [ "standoff_ns", "" ] [ "standoff_start", "start" ] [ "standoff_end", "end" ] [ "config", "D:\\Program Files\\MonetDB\\MonetDB5\\etc\\monetdb5.conf" ] [ "mero_pidfile", "D:\\Program Files\\MonetDB\\MonetDB5\\var\\run\\MonetDB\\merovingian.pid" ] [ "mero_controlport", "50001" ] [ "nov2009_pipe", "inline,remap,evaluate,costModel,coercions,emptySet,aliases,mergetable,deadcode,constants,commonTerms,joinPath,deadcode,reduce,dataflow,history,multiplex,garbageCollector" ] [ "replication_pipe", "inline,remap,evaluate,costModel,coercions,emptySet,aliases,mergetable,deadcode,constants,commonTerms,joinPath,deadcode,reduce,dataflow,history,replication,multiplex,garbageCollector" ] [ "accumulator_pipe", "inline,remap,evaluate,costModel,coercions,emptySet,aliases,mergetable,deadcode,constants,commonTerms,joinPath,deadcode,reduce,accumulators,dataflow,history,multiplex,garbageCollector" ] [ "recycler_pipe", "inline,remap,evaluate,costModel,coercions,emptySet,aliases,deadcode,constants,commonTerms,joinPath,deadcode,recycle,reduce,dataflow,history,multiplex,garbageCollector" ] [ "cracker_pipe", "inline,remap,evaluate,costModel,coercions,emptySet,aliases,selcrack,deadcode,constants,commonTerms,joinPath,deadcode,reduce,dataflow,history,multiplex,garbageCollector" ] [ "sidcrack_pipe", "inline,remap,evaluate,costModel,coercions,emptySet,aliases,sidcrack,deadcode,constants,commonTerms,joinPath,deadcode,reduce,dataflow,history,multiplex,garbageCollector" ] [ "datacell_pipe", "inline,remap,evaluate,costModel,coercions,emptySet,aliases,deadcode,constants,commonTerms,joinPath,datacell,deadcode,reduce,dataflow,history,multiplex,garbageCollector" ] [ "octopus_pipe", "inline,remap,evaluate,costModel,coercions,emptySet,aliases,mitosis,mergetable,deadcode,constants,commonTerms,joinPath,octopus,deadcode,reduce,dataflow,history,multiplex,garbageCollector" ] [ "mapreduce_pipe", "inline,remap,evaluate,costModel,coercions,emptySet,aliases,mapreduce,mergetable,deadcode,commonTerms,joinPath,reorder,deadcode,reduce,dataflow,history,multiplex,garbageCollector" ] [ "datacyclotron_pipe", "inline,remap,evaluate,costModel,coercions,emptySet,aliases,datacyclotron,mergetable,deadcode,constants,commonTerms,joinPath,reorder,deadcode,reduce,dataflow,history,replication,multiplex,garbageCollector" ] [ "derive_pipe", "inline,remap,evaluate,costModel,coercions,emptySet,aliases,mergetable,deadcode,constants,commonTerms,derivePath,joinPath,deadcode,reduce,dataflow,history,multiplex,garbageCollector" ] [ "dictionary_pipe", "inline,remap,dictionary,evaluate,costModel,coercions,emptySet,aliases,mergetable,deadcode,constants,commonTerms,joinPath,deadcode,reduce,dataflow,history,multiplex,garbageCollector" ] [ "compression_pipe", "inline,remap,evaluate,costModel,coercions,emptySet,aliases,mergetable,deadcode,constants,commonTerms,joinPath,deadcode,reduce,dataflow,compression,dataflow,history,multiplex,garbageCollector" ] [ "gdk_mem_pagebits", "16" ] [ "gdk_mem_bigsize", "1048576" ] [ "monet_pid", "984" ] [ "monet_version", "5.22.3" ] RD 1298855541546: inserting prompt TD 1298855541562: write final block: 60 bytes TX 1298855541562: sselect * from risk.td_ind_security_held where id = 1560000; RD 1298855541578: read final block: 1600 bytes RX 1298855541578: &1 1 1 30 1 % risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held # table_name % id, bizdate, painnercode, currency, exchange, seccode, basickind, unrealizedgainchange, unrealizedgain, margingain, interestgain, othergain, yieldrate, accrualinterest, allgain, fullmv, marketvalue, lastfullmv, lastmarketvalue, lastcost, cost, buysum, sellsum, realizedgain, holdingqty, lastholdingqty, mvweight, lastmvweight, fullmvweight, lastfullmvweight # name % int, varchar, varchar, varchar, varchar, varchar, varchar, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal # type % 7, 8, 8, 3, 5, 6, 3, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 14, 14, 14, 14 # length RD 1298855541578: inserting prompt TD 1298855762109: write final block: 60 bytes TX 1298855762109: sselect * from risk.td_ind_security_held where id = 1560000; RD 1298855762125: read final block: 1600 bytes RX 1298855762125: &1 2 1 30 1 % risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held # table_name % id, bizdate, painnercode, currency, exchange, seccode, basickind, unrealizedgainchange, unrealizedgain, margingain, interestgain, othergain, yieldrate, accrualinterest, allgain, fullmv, marketvalue, lastfullmv, lastmarketvalue, lastcost, cost, buysum, sellsum, realizedgain, holdingqty, lastholdingqty, mvweight, lastmvweight, fullmvweight, lastfullmvweight # name % int, varchar, varchar, varchar, varchar, varchar, varchar, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal, decimal # type % 7, 8, 8, 3, 5, 6, 3, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 14, 14, 14, 14 # length RD 1298855762125: inserting prompt TD 1298856279453: write final block: 69 bytes TX 1298856279453: sselect id,bizdate from risk.td_ind_security_held where id = 1560000; RD 1298856279453: read final block: 162 bytes RX 1298856279453: &1 3 1 2 1 % risk.td_ind_security_held, risk.td_ind_security_held # table_name % id, bizdate # name % int, varchar # type % 7, 8 # length [ 1560000, "20090702" ] RD 1298856279453: inserting prompt TD 1298856279468: write final block: 1797 bytes TX 1298856279468: sSELECT 'krisk' AS "TABLE_CAT", "schemas"."name" AS "TABLE_SCHEM", "tables"."name" AS "TABLE_NAME", "columns"."name" AS "COLUMN_NAME", cast(CASE "columns"."type" WHEN 'wrd' THEN -5 WHEN 'sec_interval' THEN -5 WHEN 'bigint' THEN -5 WHEN 'timetz' THEN 92 WHEN 'char' THEN 1 WHEN 'int' THEN 4 WHEN 'clob' THEN 2005 WHEN 'month_interval' THEN 4 WHEN 'tinyint' THEN -6 WHEN 'table' THEN 2003 WHEN 'date' THEN 91 WHEN 'double' THEN 8 WHEN 'decimal' THEN 3 WHEN 'timestamptz' THEN 93 WHEN 'timestamp' THEN 93 WHEN 'blob' THEN 2004 WHEN 'real' THEN 7 WHEN 'time' THEN 92 WHEN 'oid' THEN 1111 WHEN 'boolean' THEN 16 WHEN 'smallint' THEN 5 WHEN 'varchar' THEN 12 ELSE 1111 END AS smallint) AS "DATA_TYPE", "columns"."type" AS "TYPE_NAME", "columns"."type_digits" AS "COLUMN_SIZE", "columns"."type_scale" AS "DECIMAL_DIGITS", 0 AS "BUFFER_LENGTH", 10 AS "NUM_PREC_RADIX", cast(CASE "null" WHEN true THEN 1 WHEN false THEN 0 END AS int) AS "NULLABLE", cast(null AS varchar(1)) AS "REMARKS", "columns"."default" AS "COLUMN_DEF", 0 AS "SQL_DATA_TYPE", 0 AS "SQL_DATETIME_SUB", 0 AS "CHAR_OCTET_LENGTH", "columns"."number" + 1 AS "ORDINAL_POSITION", cast(null AS varchar(1)) AS "SCOPE_CATALOG", cast(null AS varchar(1)) AS "SCOPE_SCHEMA", cast(null AS varchar(1)) AS "SCOPE_TABLE", cast(1111 AS smallint) AS "SOURCE_DATA_TYPE", CASE "null" WHEN true THEN CAST ('YES' AS varchar(3)) WHEN false THEN CAST ('NO' AS varchar(3)) END AS "IS_NULLABLE" FROM "sys"."columns" AS "columns", "sys"."tables" AS "tables", "sys"."schemas" AS "schemas" WHERE "columns"."table_id" = "tables"."id" AND "tables"."schema_id" = "schemas"."id" AND LOWER("schemas"."name") LIKE 'risk' AND LOWER("tables"."name") LIKE 'td_ind_security_held' AND LOWER("columns"."name") LIKE 'id' ORDER BY "TABLE_SCHEM", "TABLE_NAME", "ORDINAL_POSITION"; RD 1298856279484: read final block: 853 bytes RX 1298856279484: &1 4 1 22 1 % ., sys.schemas, .tables, .columns, ., .columns, .columns, .columns, ., ., ., ., .columns, ., ., ., ., ., ., ., ., . # table_name % TABLE_CAT, TABLE_SCHEM, TABLE_NAME, COLUMN_NAME, DATA_TYPE, TYPE_NAME, COLUMN_SIZE, DECIMAL_DIGITS, BUFFER_LENGTH, NUM_PREC_RADIX, NULLABLE, REMARKS, COLUMN_DEF, SQL_DATA_TYPE, SQL_DATETIME_SUB, CHAR_OCTET_LENGTH, ORDINAL_POSITION, SCOPE_CATALOG, SCOPE_SCHEMA, SCOPE_TABLE, SOURCE_DATA_TYPE, IS_NULLABLE # name % char, varchar, varchar, varchar, smallint, varchar, int, int, tinyint, tinyint, int, varchar, varchar, tinyint, tinyint, tinyint, int, varchar, varchar, varchar, smallint, varchar # type % 5, 4, 20, 2, 1, 3, 2, 1, 1, 2, 1, 0, 0, 1, 1, 1, 1, 0, 0, 0, 4, 2 # length [ "krisk", "risk", "td_ind_security_held", "id", 4, "int", 32, 0, 0, 10, 0, NULL, NULL, 0, 0, 0, 1, NULL, NULL, NULL, 1111, "NO" ] RD 1298856279484: inserting prompt TD 1298856279500: write final block: 1802 bytes TX 1298856279500: sSELECT 'krisk' AS "TABLE_CAT", "schemas"."name" AS "TABLE_SCHEM", "tables"."name" AS "TABLE_NAME", "columns"."name" AS "COLUMN_NAME", cast(CASE "columns"."type" WHEN 'wrd' THEN -5 WHEN 'sec_interval' THEN -5 WHEN 'bigint' THEN -5 WHEN 'timetz' THEN 92 WHEN 'char' THEN 1 WHEN 'int' THEN 4 WHEN 'clob' THEN 2005 WHEN 'month_interval' THEN 4 WHEN 'tinyint' THEN -6 WHEN 'table' THEN 2003 WHEN 'date' THEN 91 WHEN 'double' THEN 8 WHEN 'decimal' THEN 3 WHEN 'timestamptz' THEN 93 WHEN 'timestamp' THEN 93 WHEN 'blob' THEN 2004 WHEN 'real' THEN 7 WHEN 'time' THEN 92 WHEN 'oid' THEN 1111 WHEN 'boolean' THEN 16 WHEN 'smallint' THEN 5 WHEN 'varchar' THEN 12 ELSE 1111 END AS smallint) AS "DATA_TYPE", "columns"."type" AS "TYPE_NAME", "columns"."type_digits" AS "COLUMN_SIZE", "columns"."type_scale" AS "DECIMAL_DIGITS", 0 AS "BUFFER_LENGTH", 10 AS "NUM_PREC_RADIX", cast(CASE "null" WHEN true THEN 1 WHEN false THEN 0 END AS int) AS "NULLABLE", cast(null AS varchar(1)) AS "REMARKS", "columns"."default" AS "COLUMN_DEF", 0 AS "SQL_DATA_TYPE", 0 AS "SQL_DATETIME_SUB", 0 AS "CHAR_OCTET_LENGTH", "columns"."number" + 1 AS "ORDINAL_POSITION", cast(null AS varchar(1)) AS "SCOPE_CATALOG", cast(null AS varchar(1)) AS "SCOPE_SCHEMA", cast(null AS varchar(1)) AS "SCOPE_TABLE", cast(1111 AS smallint) AS "SOURCE_DATA_TYPE", CASE "null" WHEN true THEN CAST ('YES' AS varchar(3)) WHEN false THEN CAST ('NO' AS varchar(3)) END AS "IS_NULLABLE" FROM "sys"."columns" AS "columns", "sys"."tables" AS "tables", "sys"."schemas" AS "schemas" WHERE "columns"."table_id" = "tables"."id" AND "tables"."schema_id" = "schemas"."id" AND LOWER("schemas"."name") LIKE 'risk' AND LOWER("tables"."name") LIKE 'td_ind_security_held' AND LOWER("columns"."name") LIKE 'bizdate' ORDER BY "TABLE_SCHEM", "TABLE_NAME", "ORDINAL_POSITION"; RD 1298856279515: read final block: 862 bytes RX 1298856279515: &1 5 1 22 1 % ., sys.schemas, .tables, .columns, ., .columns, .columns, .columns, ., ., ., ., .columns, ., ., ., ., ., ., ., ., . # table_name % TABLE_CAT, TABLE_SCHEM, TABLE_NAME, COLUMN_NAME, DATA_TYPE, TYPE_NAME, COLUMN_SIZE, DECIMAL_DIGITS, BUFFER_LENGTH, NUM_PREC_RADIX, NULLABLE, REMARKS, COLUMN_DEF, SQL_DATA_TYPE, SQL_DATETIME_SUB, CHAR_OCTET_LENGTH, ORDINAL_POSITION, SCOPE_CATALOG, SCOPE_SCHEMA, SCOPE_TABLE, SOURCE_DATA_TYPE, IS_NULLABLE # name % char, varchar, varchar, varchar, smallint, varchar, int, int, tinyint, tinyint, int, varchar, varchar, tinyint, tinyint, tinyint, int, varchar, varchar, varchar, smallint, varchar # type % 5, 4, 20, 7, 2, 7, 1, 1, 1, 2, 1, 0, 0, 1, 1, 1, 1, 0, 0, 0, 4, 2 # length [ "krisk", "risk", "td_ind_security_held", "bizdate", 12, "varchar", 8, 0, 0, 10, 0, NULL, NULL, 0, 0, 0, 2, NULL, NULL, NULL, 1111, "NO" ] RD 1298856279515: inserting prompt TD 1298856508906: write final block: 77 bytes TX 1298856508906: sselect id,bizdate,allgain from risk.td_ind_security_held where id = 1560000; RD 1298856508906: read final block: 187 bytes RX 1298856508906: &1 6 1 3 1 % risk.td_ind_security_held, risk.td_ind_security_held, risk.td_ind_security_held # table_name % id, bizdate, allgain # name % int, varchar, decimal # type % 7, 8, 20 # length RD 1298856508906: inserting prompt

10 years, 7 months

[MonetDB-users] java.lang.AssertionError: block 0 should have been fetched by now

by Viktor Rosenfeld

Hi, I get an error message when I retrieve a MAL plan over JDBC after the 250th call to ResultSet.next(). The relevant part of the stack trace is: java.lang.AssertionError: block 0 should have been fetched by now :( at nl.cwi.monetdb.jdbc.MonetConnection$ResultSetResponse.getLine(MonetConnection.java:1585) at nl.cwi.monetdb.jdbc.MonetResultSet.absolute(MonetResultSet.java:194) at nl.cwi.monetdb.jdbc.MonetResultSet.relative(MonetResultSet.java:2149) at nl.cwi.monetdb.jdbc.MonetResultSet.next(MonetResultSet.java:2116) The call to EXPLAIN works in mclient and returns a MAL plan that is 402 lines long. I can reproduce the error when I try to create the plan via jdbcclient, except that it says that block 1 should have been fetched and the exporter stops after line 160 or so. However, other SQL queries that also produce more than 250 results work over JDBC. Not sure what the difference is, but these queries only return column of integers. I'm using the Aug2011-SP3 release on OS X 10.6.8. Please let me know if I should provide other information like the SQL query or the MAL plan. Cheers, Viktor

10 years, 7 months

[MonetDB-users] time series data scaling

by David Pennell

In a large scale time series row-store DB (Oracle), I'm accustomed to partitioning fact tables on time. This has has a couple of benefits: - since queries always include predicates on the time field, partition elimination can help a lot - when the time based partitions map one-to-one with tablespaces, removing old data is extremely fast. (when you've reached the maximum data retention period, you need to remove data as fast as you can load it). Are there any features in monetdb that would facilitate these needs (or ameliorate them)? TIA, -david

10 years, 7 months

[MonetDB-users] Benefits of sorted columns

by Viktor Rosenfeld

Hi, I know that when a table is sorted on a column, value look-ups on that column will use a binary search instead of a linear search. Is there a similar benefit for joins? E.g. if I have 2 tables that contain a sorted column C and I do an equality join on this column (or a self-join using 2 aliases of the same table), I would expect a traditional DBMS to do a merge-join. Cheers, Viktor

10 years, 7 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

users-list December 2011