Daniel Freedman wrote:
On the topic of query cache (or maybe this is just tangential and I'm
confused):
I've always heard that Oracle has the ability to essentially suck in as
much of the database into RAM as you have memory to allow it, and can then
just run its queries on that in-RAM
Howdy-
Is there a way to change the delimiters for character/date types from
single quotes to any other character?
For instance, if I'm inserting "O'Brien", rather than doing something like
INSERT INTO Names VALUES ('O''Brien'); I'd like to be able to use: INSERT
INTO Names VALUES (~O'Brien~);
PostgreSQL hits the disk on UPDATE/DELETE/INSERT operations. SELECT's
are cached, but the default cache is only ½MB of RAM. You can change
this to whatever you want.
I'm using Cold Fusion and it can cache queries itself, so no database
action is necessary. But I don't think PHP and others
I apologize for the second post- I think my digital signature may have
screwed up the first one, so I'm sending this again just to be sure... -NF
Howdy-
Is there a way to change the delimiters for character/date types from
single quotes to any other character?
For instance, if I'm inserting
On Wed, Nov 01, 2000 at 10:16:58AM +, Poul L. Christiansen wrote:
PostgreSQL hits the disk on UPDATE/DELETE/INSERT operations. SELECT's
are cached, but the default cache is only ½MB of RAM. You can change
this to whatever you want.
That sound like a very cool thing to do, and the default
If I remove the "GROUP BY messages.msgid ...", then the result will be
messages whose subject contains either 'Hello' or 'There' in the
subject, but not necessarily both.
I want messages which have both 'Hello' and 'There' in the subject, and
both 'Jim' and 'Jones' in the author.
(For example,
On 31 Oct 2000, Gary Howland wrote:
Just a quickie - I heard that linux does not have a working fsync() call
At least the manpage for fsync says that it does.
The implementation:
/* .. finally sync the buffers to disk */
dev = inode-i_dev;
return sync_buffers(dev, 1);
Hello everybody,
We have a MySQL database, and we're planning to migrate all to a PostgreSQL
database. We must migrate all the data to a development system, in order to
take real performance numbers. The problem is we don't know how to convert the
files generated by mysqldump in order to
Frank Joerdens wrote:
On Wed, Nov 01, 2000 at 10:16:58AM +, Poul L. Christiansen wrote:
PostgreSQL hits the disk on UPDATE/DELETE/INSERT operations. SELECT's
are cached, but the default cache is only ½MB of RAM. You can change
this to whatever you want.
That sound like a very cool
Can I use chinese as the column header?
Thanks
Dave
In general I am pretty pissed at RH attitude to system
upgrade, if I were working in a Production environment,
I would either hire them and not try anything myself,
which kinda contradicts the whole Linux philosophy.
Can this kind of stuff get put on a Red Hat mailing list, rather than sent
It also relates back to a post I made many moons ago. I don't upgrade any
OS (outside of minor patches). If it is a new OS version, backup and then
clean install. Just too many variables to contend with to trust a type of
upgrade script.
Adam Lang
Systems Engineer
Rutgers Casualty Insurance
I wouldn't say ditch out on Redhat because of Postgres upgrades. As was
mentioned on the list before, there is no current silver bullet upgrade for
postgres. Dump, install new version, import old data. I would assume then
that means SUSE would be no better on that regard either.
Also, any bad
select * from myTable where upper(myField) like 'TEST';
Upper will change the fields to upper case for testing purposes.
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
- Original Message -
From: "Yann Ramin" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday,
"Robert D. Nelson" wrote:
In general I am pretty pissed at RH attitude to system
upgrade, if I were working in a Production environment,
I would either hire them and not try anything myself,
which kinda contradicts the whole Linux philosophy.
Can this kind of stuff get put on a Red Hat
Or use the regular expression syntax for case insensitive pattern matching
e.g. SELECT foo FROM bar WHERE foo *= 'aBc';
For more info, see:
http://www.postgresql.org/users-lounge/docs/7.0/user/operators2123.htm
Hope that helps,
Ol.
select * from myTable where upper(myField) like 'TEST';
I'm working with version 6.5.2 and I've created a test table that
contains both a one and a two dimensional array.
CREATE TABLE testa (
name text,
links int2[],
vals int2[][] );
I'v populated the table with at least one record, so I should be able
run 'select' requests that
Is there an upper limit on the size of a "text" character field? If so,
how can I extend it?
Thanks,
John
begin:vcard
adr;dom:;;232 E. Lyons;Spokane;WA;99208;
n:Pilley;John
x-mozilla-html:FALSE
org:Settlement Plus, Inc.
version:2.1
email;internet:[EMAIL PROTECTED]
title:Software Engineer
On Wed, 1 Nov 2000, John Burski wrote:
I'm working with version 6.5.2 and I've created a test table that
contains both a one and a two dimensional array.
CREATE TABLE testa (
name text,
links int2[],
vals int2[][] );
I'v populated the table with at least one
I couldn't find anything in the man page about this -- does psql check for
~/.psql or anything so I don't have to manually --pset pager=off every time
I run it? If there is such a file, what is the format for specifying
options?
-Jonathan
John-
According to the documentation and Bruce M's book, there is no limit. I've
never hit a limit while putting some pretty large (three page) narratives in
a text field. Practically speaking, I would guess that one will take a
performance hit due to fragmentation when storing big chunks of
Hello,
I need a tool to interactively visualize (not administer) DB tables from
a web interface. Ideally this tool would let me:
- rename column headers,
- set cell alignments, widths, background colors,
- reorder columns,
- save all these visualisation settings in a DB,
- it would be written
This requires you to change NAMEDATALEN in src/include/postgres_ext.h.
Note this requires a recompile, initdb, createdb, etc.
Also note that databases with different NAMEDATALEN's can't interoperate.
Wade
Hello,
Looking at the docs for pgsql I have only found stuff on altering a table
On Wed, Nov 01, 2000 at 12:32:58PM -0500, Nick Fankhauser wrote:
According to the documentation and Bruce M's book, there is no limit. I've
never hit a limit while putting some pretty large (three page) narratives in
a text field.
There is no limit on the "text" type as such, but there is
Hardwood floors and more! See the natural beauty of hardwood flooring and hardwood
designs at www.classicdistributors.com or http://209.35.59.31!
set digest
26 matches
Mail list logo