Home > Archive > PostgreSQL Discussion > April 2005 > Thanks for Rekall link!









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Thanks for Rekall link!
Typing80wpm@aol.com

2005-04-27, 8:24 pm

Thanks for the link and the info. I went there and, sure enough, there is a
free windows version of Rekall as well as a 25 Pound (British Sterling?)
version for Windows. The message board forum looks very useful. They have a
news item about Novell certification/approval ....

I must say one intereting thing. When I downloaded the trial version from
TheKompany, and asked it to browse a test file in PGSql which I loaded with
250,000 rows, it started to read them, and read for a long long time (as
MSAccess does), but the seemed to get stuck, whereas MSAccess is able to browse the
entire file. I must experiment more with the demo version from theKompany,
and also with this free version from the site you gave me.
====================
===========

Quoth Typing80wpm@aol.com:
> I just downloaded the windows demo for Rekall, which is an MSAccess
> like product (loosely speaking) with native drivers for postgresql
> and some other engines (plus odbc for yet others). I was a bit
> confused on certain things so I emailed my questions, and the
> president of the company replied.
>
> It wasnt clear what product I should purchase for windows, and he
> said that the basic $60 rekall gives you both windows and linux
> versions.
>
> I was also unclear about how long the demo remains active (30 days,
> 10 days?) but he explained that the demo never expires, remains
> active indefinitely, but logs off ever 20 minutes. It unzipped and
> installed effortlessly on my part. And it was very simple to tell
> it to look at a postgresql database. It uses python as a scripting
> language.
>
> I havent done a lot with it yet, but I think I am going to like it a
> lot.


It is worth noting that the authors of Rekall are quite separate from
"theKompany."

Before you consider paying TheKompany for licenses, you might want to
take a peek at the authors' web site...

<http://totalrekall.co.uk/>

And pay particular attention to the FAQ, especially the part where
theKompany is mentioned...

<http://totalrekall.co.uk/modules.php?name=FAQ>
--
wm(X,Y):- write(X),write('@'),
write(Y). wm('cbbrowne','ntlug
.org').
http://linuxdatabases.info/info/slony.html
Rules of the Evil Overlord #42. "When I capture the hero, I will make
sure I also get his dog, monkey, ferret, or whatever sickeningly cute
little animal capable of untying ropes and filching keys happens to
follow him around." <http://www.eviloverlord.com/>

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match


Christopher Browne

2005-04-28, 3:24 am

A long time ago, in a galaxy far, far away, Typing80wpm@aol.com wrote:
> I must say one intereting thing. When I downloaded the trial version
> from TheKompany, and asked it to browse a test file in PGSql which I
> loaded with 250,000 rows, it started to read them, and read for a
> long long time (as MSAccess does), but the seemed to get stuck,
> whereas MSAccess is able to browse the entire file._ I must
> experiment more with the demo version from theKompany, and also with
> this free version from the site you gave me.


This sort of problem is characteristic of the use of "array" objects
in graphical toolkits.

Suppose you're populating something with 250K rows, perhaps with a
dozen fields per row. In such a case, the toolkit is slinging around
3-4 million objects, and having to evaluate which of them are visible
on screen at any given time.

_Any_ kind of inefficiency in the library, or in the use of the
library, can easily lead to rendering turning out really, really
badly.

The X Window system has gotten heavily criticized for speed problems,
commonly with respect to how Mozilla used to work when rendering large
web pages. Reality was that Mozilla was implemented (this is no
longer true, by the way) atop a platform-independent library called
Rogue Wave which then had a mapping to Motif (which is noted as Not
Everyone's Favorite Graphics Library ;-)) which then rendered things
using X. The True Problem lay somewhere in that set of layers and,
since several of the layers were pretty inscrutable, it was
essentially impractical to address the performance problem.

Much the same thing took place with the Tcl/Tk application, "cbb"
(Check Book Balancer); the Tk 'array' object got to behave
increasingly badly with increasing thousands of rows. And changing
one transaction near the top of an account would lead to cascading
balance updates, therefore walking (linear fashion, more than likely
leading to superlinear resource consumption :-() through the rest of
the transactions to update every single balance...

Gigahertz, Gigabytes, and upgrades may overcome that, to some degree,
but it wouldn't be overly surprising if you were hitting some such
unfortunate case. It might represent something fixed in a later
release of Rekall; it could represent something thorny to resolve.

I would really hate the notion of depending on a GUI to manage
millions of objects in this manner; it is just so easy for it to go
badly.
--
"cbbrowne","@","gmail.com"
http://linuxdatabases.info/info/nonrdbms.html
Rules of the Evil Overlord #10. "I will not interrogate my enemies in
the inner sanctum -- a small hotel well outside my borders will work
just as well." <http://www.eviloverlord.com/>
Sponsored Links





Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive | Programming forum archive

Copyright 2008 droptable.com