users-list December 2005

users-list@monetdb.org

1 participants
2 discussions

by Henk van Lingen

Hi, Is there a special reason there are no i686 RPM's anymore like there were until 4.6.0_rc2? I think it's a bit weird there are RPM's for the hobby OS 'FedoraCore' but not for the much used server OS 'RedHat Enterprise 3 (and 4)'? The FedoraCore (which Core?) needs libstdc++.so.6 whereas RHEL 3 only has libstdc++.so.5 ... There also seems to be no SRPM's. Cheers, -- Henk van Lingen, Systems & Network Administrator (o- -+ Dept. of Computer Science, Utrecht University. /\ | phone: +31-30-2535278 v_/_ http://henk.vanlingen.net/ http://www.tuxtown.net/netiquette/

16 years, 3 months

[MonetDB-users] MonetDB/Five slotting: on running M4 next to M5

by Fabian Groffen

Hi list, Scheduled for next year is the (alpha/beta) release of MonetDB/Five, the successor of the current MonetDB generation. MonetDB/Five is the logical successor to its predecessor in terms of speed and performance. However, MonetDB/Five is not fully backwards compatible with it's predecessor. Instead of using the MIL language for kernel operations, it uses MAL. Although many MIL operations can be easily mapped on MAL operations, a fully automatic (and correct) translation of MIL to MAL is not possible. Directly related to this, is the availability of MonetDB/XQuery, which currently heavily relies on the MIL language. The SQL users of MonetDB will be the only ones that will immediately benefit from the improved MonetDB/Five engine, as SQL is fully functional and there is no difference in language or output. Due to this situation where both M4 (curent MonetDB generation) and M5 (MonetDB/Five generation) have it's own advantages (XQuery support, MIL, MAL, better performance) it is most likely that one would like to run both M4 and M5 engines next to each other to benefit from both. This would currently cause problems when applied out of the box. Given that M4 and M5 would be slotted, and hence installable next to each other, starting it's services would cause problems because both engines try to bind to the same ports by default. To give a short view on the ports in use by default: M4 M5 Mapi 50000 50000 SQL 45123 45123 XQuery 45789 N/A This obviously clases for default MIL/MAL (Mapi) connections as well as SQL connections. XQuery is not an issue for the moment. A few observations: - The actual language spoken over the Mapi server port is engine specific, i.e. MIL for M4 and MAL for M5. This is probably somewhat confusing. For SQL it is clear, and the port specifies which language to use, regardless the engine. - XQuery support is not available for M5 yet, but it should be dealt with as for SQL. Possible scenarios to solve the problems of clashing ports can be: 1. Use different port numbers based on the engine, i.e. use 55123 for SQL on M5 and 45123 on M4. Mapi could become something like 50005 for M5. 2. Build (or extend for instance the DatabasePool) an application that handles transparently the request for a service making use of a combination of port and challenge response to give the client a M4 MIL, M5 MAL, M5 SQL or M4 XQuery connection, using the ports currently known. (Note: this also allows for multi-catalog support for SQL, when the DatabasePool is taken as base.) 3. Ignore the problem and only document it, including how to change the default ports to avoid clashes. (Note: unfortunately we're unable to bind to a certain interface...) 4. A combination between 1 and 2, with the purpose of getting each language it's own port in the system, reducing the problem and possibly disable M4's SQL server. Are end-users interested in/aided by such changes made, or will they figure out themselves easily enough? Just a few thoughts on a problem that will arise in distribution land...

16 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 2005