*** dyki has joined #ingres | 00:00 | |
*** DarylM has joined #ingres | 00:01 | |
pboro | damn it's slow to COPY a table with a lot of LONG VARCHARs, even they don't contain a lot of data | 01:18 |
---|---|---|
Alex| | every long varchar adds an overhead of reading another page... | 01:51 |
Alex| | for smaller lobs this will change when Ingres supports inline lobs | 01:51 |
*** Deyan has joined #ingres | 02:26 | |
Deyan | good morning, gents | 02:26 |
pboro | Alex|, ahh... inline lobs, GREAT :) | 02:43 |
pboro | I need 64kB varchar columns for some texts, LONG VARCHAR is simply too much for it... | 02:44 |
Alex| | you can have 64k in varchar columns | 02:54 |
pboro | yeah, but... page size limits :) | 02:55 |
pboro | inst 64k maximum page size? | 02:55 |
Alex| | since 9.2 (?) we have page spanning, which means you can have varchars that are longer than your page size | 02:55 |
pboro | isn't even | 02:55 |
Alex| | up to 256k | 02:55 |
pboro | oh :-o well, 256k is not enough still | 02:55 |
pboro | I need eight of them | 02:55 |
Alex| | ah, well... no I think 256k is the widest row we support currently | 02:56 |
Alex| | split the table :) | 02:56 |
pboro | I considered creating (id, name, value) for it, ie. break the columns in rows | 02:56 |
pboro | but have not yet tried that, since it would need extra work to make sure that there's always certain rows for each ids | 02:57 |
Deyan | why long varchar? | 03:07 |
Deyan | why not make it a blob | 03:07 |
Deyan | ? | 03:07 |
*** dyki_ has joined #ingres | 03:07 | |
Deyan | hey dyki_ \o/ | 03:07 |
Deyan | long time no see mate | 03:07 |
dyki_ | yo | 03:07 |
Deyan | :P | 03:07 |
dyki_ | i have clonned somehow :D | 03:07 |
pboro | Deyan, long varchar is in practice, a blob | 03:08 |
Deyan | yeah | 03:08 |
pboro | so it would not help | 03:08 |
*** dyki has quit IRC | 03:13 | |
atrofast | Yeah but with blobs you wouldn't run into the page size problem | 03:13 |
atrofast | So you could have tons of long varchars on any page size :) | 03:15 |
Deyan | that is why i thought that | 03:15 |
atrofast | I could be missing something... Just woke up and my brain is still booting :P | 03:16 |
pboro | Hmm... that's strainge, why put on arbitrary limit on clobs but not blob? | 03:16 |
pboro | ahh, misread... yeah, but it still wont help | 03:17 |
pboro | whether it's clob or blob, it's damn slow :) | 03:17 |
pboro | because of the extra etab table and another page reading... | 03:17 |
atrofast | Ah well you got me there, although there is a project to improve the performance of blobs | 03:18 |
Deyan | i thought BLOB/TEXT columns take 9-12 bytes | 03:18 |
Deyan | in the row | 03:18 |
Deyan | similar to MyISAM tables | 03:19 |
pboro | Deyan, yeah, they do, it's just a "pointer" to another table which actually contains the data | 03:19 |
atrofast | Seems like a long varchar actually has a width of 33 bytes | 03:20 |
Deyan | 33 ? | 03:21 |
Deyan | wow | 03:21 |
Deyan | i would like to see .src.rpm for ingres packages :D | 03:24 |
Deyan | are they in the svn? | 03:24 |
atrofast | As far as I know, no. You can download the source along side builds from esd.ingres.com | 03:34 |
atrofast | But it's just a tar file | 03:34 |
Deyan | i think i will do the CMake support for Ingres at some stage | 03:35 |
Deyan | once i have enough time for that | 03:36 |
Deyan | Ingres source tree is huge | 03:36 |
* atrofast thinks that's an awesome idea | 03:39 | |
atrofast | have you ever done jam->cmake before? | 03:40 |
Deyan | nope, i am going to ignore Jam | 03:47 |
Deyan | completely | 03:47 |
Deyan | sure i will read jam files just to get a clue where is what | 03:47 |
atrofast | Ah, I think jam -dx will output the stuff you need (compile commands etc) | 03:50 |
Deyan | my first priority would actually be to make ingres build on 64bit | 03:52 |
Deyan | and use only 64bit stuff | 03:53 |
Deyan | :D | 03:53 |
Deyan | because i am sick of 32bit support | 03:53 |
Deyan | and installing all those prerequisities for 32bit build that i actually do not need at all | 03:53 |
Deyan | in fact, we here do not have 32bit machines i think | 03:53 |
*** Gerhard has joined #ingres | 04:37 | |
Deyan | hello Gerhard | 04:49 |
*** DerMeister has joined #ingres | 04:59 | |
Gerhard | Hi Deyan | 05:03 |
*** rossand has joined #ingres | 05:31 | |
*** ChanServ sets mode: +o rossand | 05:31 | |
*** toumi01 has left #ingres | 05:47 | |
*** toumi01 has joined #ingres | 05:58 | |
*** DerMeister has quit IRC | 06:02 | |
*** toumi01 has left #ingres | 06:03 | |
*** thiagomz has joined #ingres | 06:08 | |
*** toumi01 has joined #ingres | 06:11 | |
*** rossand has quit IRC | 06:20 | |
*** rossand has joined #ingres | 06:26 | |
*** ChanServ sets mode: +o rossand | 06:26 | |
rossand | Deyan: I am quite interested in what you've said - 64 bit w/o 32 bit libs and cmake. If you ever decide you want to forge ahead, please ping me and I'll rally support for this. It is very worthwhile. | 06:32 |
rossand | If done right, the work to implement cmake could enable using multi-core for parallel builds. i.e. builds go a heck of a lot faster. | 06:33 |
DarylM | . | 06:33 |
DarylM | My Mac OS/X 64 bit build is 64 bit only. No 32 bit. | 06:35 |
atrofast | Does it run through the test suite without errors? | 06:35 |
DarylM | Have not run the official test suite. | 06:36 |
DarylM | It is a work in progress | 06:36 |
rossand | DarylM: sounds great. Might be worth trying to run the tests to expose the issues 1) with running the tests on MacOS and then 2) With the port in general | 06:36 |
DarylM | I know for certain that it already >fixed< several problems with the Mac port :) | 06:37 |
rossand | Running the tests works decent on Ubuntu/Fedora/Suse 32 bit. 64 is ok I think as well though can't speak first hand myself. | 06:37 |
Deyan | rossand: even more | 06:41 |
Deyan | cmake would enable ingres developers an excellent dashboard utility | 06:41 |
Deyan | which i think would be very, very helpful | 06:41 |
Deyan | so you can immediately see what fails to build, and where | 06:42 |
Deyan | dashboard is the main reason why I started using CMake long ago | 06:42 |
rossand | Deyan: Sounds handy. Is it really that much better than say jam -q? | 06:45 |
Alex| | I've had cases where jam -q didn't stop in case of an error - so anything that stops at an error is better ;) | 06:46 |
DarylM | jam -q with other options never stops form me | 06:46 |
DarylM | for* | 06:46 |
DarylM | Actually, I really really dislike jam | 06:46 |
* DarylM thinks jelly is not so bad though.... | 06:47 | |
Deyan | www.cdash.org | 06:47 |
rossand | That's good to know. Unfortunate when a tool doesn't work (jam -q) as it should. | 06:49 |
rossand | It sounds like there are a half dozen or so people who would be interested in helping to give cmake a go. If you guys are serious, just say so and we can create a branch to start chipping away at it. | 06:50 |
rossand | It's a pretty itchy itch to scratch. | 06:50 |
*** mull has joined #ingres | 07:07 | |
Deyan | i can always make a branch for myself :) | 07:08 |
Deyan | and make a local git out of the current tree | 07:08 |
Deyan | for personal play | 07:08 |
*** Alex| is now known as Alex|off | 07:10 | |
Deyan | i would like to have support for ingres in PDO... | 07:22 |
*** rossand1 has joined #ingres | 07:23 | |
DarylM | Have at it :) | 07:24 |
*** rossand has quit IRC | 07:41 | |
*** Gerhard has left #ingres | 07:58 | |
*** Alex|off is now known as Alex| | 10:05 | |
*** Deyan has quit IRC | 10:12 | |
thiagomz | guys, how can i generate a script to migrate tables from 4k to 8k ? | 11:20 |
thiagomz | usermod should be a good choice, but it always execute the command... | 11:25 |
thiagomz | i wanna just the script... | 11:25 |
thiagomz | so after that i could use vi to replace 4096 to 8192... | 11:25 |
thiagomz | copydb !!!! | 11:32 |
thiagomz | it will work | 11:32 |
pboro | yeah, that will work :) | 11:33 |
atrofast | thiagomz: yeah copydb should work, or you can use unloaddb which unloads everything | 11:37 |
*** Alex| is now known as Alex|off | 11:39 | |
thiagomz | atrofast: worked | 11:41 |
atrofast | Cool! | 11:42 |
thiagomz | i did a select and i got the table_names | 11:42 |
thiagomz | with awk i change the columns to lines | 11:42 |
thiagomz | copydb -with_modify | 11:42 |
thiagomz | vi s/4096/8192/g | 11:42 |
thiagomz | ;) | 11:42 |
thiagomz | just to keep in logs... | 11:43 |
thiagomz | awk '{a=$0;getline;printf "%s",a,$0}' base > base-in-line | 11:43 |
thiagomz | sql database -udba < copy.in | tee copy.log | 11:43 |
*** rossand1 has quit IRC | 12:41 | |
*** zxiiro has joined #ingres | 13:23 | |
*** ChanServ sets mode: +v zxiiro | 13:23 | |
*** zxiiro has quit IRC | 13:43 | |
*** zxiiro has joined #ingres | 13:48 | |
*** ChanServ sets mode: +v zxiiro | 13:48 | |
atrofast | Any Ingres backend guru on? If I use qec_malloc(ulm) etc etc, do I have to worry about freeing that memory myself? Or is that done when the stream is closed? | 13:50 |
atrofast | I assume not, I don't see it done in other places | 13:53 |
*** thiagomz_ has joined #ingres | 13:58 | |
*** rossand has joined #ingres | 14:15 | |
*** ChanServ sets mode: +o rossand | 14:15 | |
*** thiagomz has quit IRC | 14:15 | |
*** zxiiro has quit IRC | 14:26 | |
*** zxiiro has joined #ingres | 15:01 | |
*** ChanServ sets mode: +v zxiiro | 15:01 | |
toumi01 | atrofast: you are correct that if you use a ulm memory stream you are freeing all the sub-allocations when you free the stream | 15:04 |
*** DarylM has quit IRC | 15:25 | |
*** mull has quit IRC | 15:44 | |
*** zxiiro has quit IRC | 15:46 | |
atrofast | toumi01: Thanks! That's what I needed to make sure, don't want memory leaks :D | 15:57 |
*** rossand has quit IRC | 16:53 | |
*** toumi01 has left #ingres | 20:25 | |
*** Alex|off is now known as Alex| | 22:36 | |
*** Alex| is now known as Alex|off | 23:04 | |
*** Alex|off is now known as Alex| | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!