to complete. A UPS to allow 10 minutes of
run-time is not normally considered too expensive. Mine will run for
about an hour with new batteries, but after a few years it dwindles to
about 1/2 hour. Then I get new ones.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key
, and so on.
I use it in programs that do not necessarily use a database, but also in
programs that do when the computations are the big part of the cpu load,
as contrasted to just gentle massaging of existing data.
- --
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key
Thomas Kellerer wrote:
Jean-David Beyer wrote on 14.07.2010 14:37:
My dates are of the form -mm-dd and such.
Storing a date as a string is never a good idea.
I started this long ago, when postgreSQL did not really work very well
(1998?). One version of it would not do views, and another
.
When I had to do that, in days with smaller amounts of RAM, but very long
bit-vectors, I used a faster function sort-of like this:
static char table[256] = {
0,1,1,2,1,2,2,3,1,.
};
Then like above, but instead of the loop,
n+= table[aval];
You get the idea.
--
.~. Jean-David
criticising the O.P., since I know nothing about his application, I
am curious how it comes about that such a wide table is justified.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jerseyhttp
that
displayed answers in terms of decreasing goodness of match and stuck the
users with deciding what they wanted. A big trick was to do all this without
doing a sequential search of the database.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A
though it was possible to change the SQL string before it does the
update.. But i can't seem to find a solution for it.. Any idea ??
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jerseyhttp
Shane Ambler wrote:
Jean-David Beyer wrote:
The physical tape speed is surely the real bottleneck here, and the
fact that the total elapsed time is about the same both ways proves
that about the same number of bits went onto tape both ways.
I do not get that. If the physical tape speed
compression for average
data (e.g., not already compressed stuff like .jpeg files).
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jerseyhttp://counter.li.org
^^-^^ 10:50:01 up 23 days, 4
Andrew Sullivan wrote:
On Thu, Nov 15, 2007 at 11:05:44AM -0500, Jean-David Beyer wrote:
Does pg_dump's compression do anything really special that it is not
likely the tape drive already does? The drive claims 2:1 compression
for average data (e.g., not already compressed stuff like .jpeg
from the SEQUENCE and plug it
in each tuple as you need it.
- --
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jerseyhttp://counter.li.org
^^-^^ 07:20:01 up 28 days, 10:42, 4 users, load average
., pg_restore and pg_dump)?
I.e., can I use dd to write 65536-byte blocks to tape, and then do nothing
on running pg_restore? I.e., that pg_restore will accept any block size I
choose to offer it?
- --
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
Jean-David Beyer wrote:
The main question is, If I present pg_restore with a 65536-byte
blocksize
and it is expecting, e.g., 1024-bytes, will the rest of each block get
skipped? I.e., do I have to use dd on the way back too
I suppose to make any blocksize I want.
On the way back, likewise I could pipe the tape through dd before giving it
to pg_restore.
Does pg_dump care what blocksize it gets? If so, what is it?
- --
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruce Momjian wrote:
Jean-David Beyer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When I make a backup of a database, I put the output file directly on
magnetic tape; i.e., my command looks like this:
pg_dump --file=/dev/st0
running the test program.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jerseyhttp://counter.li.org
^^-^^ 07:45:01 up 9 days, 11:07, 3 users, load average: 4.15, 4.21, 4.13
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jean-David Beyer wrote:
It probably shows I am new to postgreSQL. I recently started running this
instead of DB2, and am converting the applications I already wrote. These
use ecpg.
The problem I have concerns transactions. I have an application
it. Is it built into the
server now, or is it to be found somewhere else? In particular, pgavd does
not exist anywhere on my system.
- --
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jerseyhttp
that will run on RHL 7.3, that
might be a problem since the current versions of postgreSQL probably all
demand a much newer kernel (RHL 7.3 used a 2.2 kernel, IIRC) and associated
libraries.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A
a suitable index for it.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jerseyhttp://counter.li.org
^^-^^ 12:25:02 up 4 days, 20:00, 3 users, load average: 4.25, 4.14, 4.12
these programs in C.
Red Hat seem to be on postgresql version 8.1.4 for the initial release of
RHEL5, and they may have updates a little higher.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey
Tom Lane wrote:
Jean-David Beyer [EMAIL PROTECTED] writes:
What is the current status of (pre) compiling Embedded SQL in C++ programs?
I just asked Michael Meskes about that (had you put a support request
into Red Hat asking this?).
Yes, and Red Hat's answer amounted to no answer at all
22 matches
Mail list logo
