MySQL and PostgreSQL are starting to move together as far as I can see.
MySQL has the _option_ of transactional database formats (you can use both
normal MyISAM tables and transactional tables). MySQL 4.0 has all those
various features you speak of. On all too many applications, MySQL kicks
ass.
> Hardware can bring a 2x gain whereas software optimization can boost an
> application by 10x. Until now, I never heard or read about a real *software
> optimization* benchmark between MySQL and PostgreSQL.
It has been my experience that a knowledgeable, SQL savvy engineer can not use
MySQL. You
At 13:07 28/10/01 -0400, you wrote:
>I'm questioning whether anyone has done benchmarks on various hardware for
>PGSQL and MySQL. I'm either thinking dual P3-866's, Dual AMD-1200's, etc.
>I'm looking for benchmarks of large queries on striped -vs- non-striped
>volumes, different processor speeds,
Tom Lane writes:
> AFAICT the client-side libpq doesn't (and shouldn't) touch signal
> handling at all, except for a couple of places in the print routines
> that temporarily block SIGPIPE.
Which was my point.
> Since we deal happily with EINTR for most of the frontend socket calls,
> I don't s
mlw <[EMAIL PROTECTED]> writes:
> My problem is, if you do a select by the user name, it does an index
> scan. If you do a select from the whole table, ordered by the user
> name, it does a sequential scan not an index scan. It is arguable that
> this may be a faster query, but at the cost of many
Hi Jean-Micehl,
* Jean-Michel POURE <[EMAIL PROTECTED]> [011028 18:23]:
>
> >psql uses your input literally - so is your console/xterm in
> >UNICODE/UTF8?
> Client: \encoding returns 'UNICODE'.
> Server: \list show databases. All databases are UNICODE (except
> TEMPLATE0 and TEMPLATE1 which are
"Steve Howe" <[EMAIL PROTECTED]> writes:
>> As long as there are at maximum 8 parameters allowed, this looks
>> practicable.
> There is no limit on the number of arguments.
You're both wrong: the limit is FUNC_MAX_ARGS, which hasn't been 8 in
quite some time. It's presently 16 by default, and c
I'm questioning whether anyone has done benchmarks on various hardware for
PGSQL and MySQL. I'm either thinking dual P3-866's, Dual AMD-1200's, etc.
I'm looking for benchmarks of large queries on striped -vs- non-striped
volumes, different processor speeds, etc.
Any thoughts people?
--
On Sun, Oct 28, 2001 at 04:37:48PM +0100, Jean-Michel POURE wrote:
> At 17:09 28/10/01 +0200, you wrote:
> >$ echo "accepté" | od -c
> It is:
> 000 a c c e p t é \n
> 010
Huh. Then try 'od -t x1'. Also what the commend 'locale'
prints.
> >Hmm. I
At 17:09 28/10/01 +0200, you wrote:
>On Sun, Oct 28, 2001 at 02:34:49PM +0100, Jean-Michel POURE wrote:
> >
> > >psql uses your input literally - so is your console/xterm in
> > >UNICODE/UTF8?
> > Client: \encoding returns 'UNICODE'.
> > Server: \list show databases. All databases are UNICODE (exc
On Sun, Oct 28, 2001 at 02:34:49PM +0100, Jean-Michel POURE wrote:
>
> >psql uses your input literally - so is your console/xterm in
> >UNICODE/UTF8?
> Client: \encoding returns 'UNICODE'.
> Server: \list show databases. All databases are UNICODE (except TEMPLATE0
> and TEMPLATE1 which are ASCII
I got an interesting question, and I can probably see both sides of any debate,
but.
Say you have a fairly large table, several million records. In this table you
have a key that has a fairly good number of duplicate rows. It is a users
favorites table, each user will have a number of entries
>psql uses your input literally - so is your console/xterm in
>UNICODE/UTF8?
Client: \encoding returns 'UNICODE'.
Server: \list show databases. All databases are UNICODE (except TEMPLATE0
and TEMPLATE1 which are ASCII of course). I use a Mandrake 8.1 distribution
and think my console is UNICODE
> We removed 'configure --enable-unicode', right? I didn't see any commit
> message about it and want to add it to the HISTORY file. If I missed
> anything else in HISTORY, please let me know.
>From cvs log:
>revision 1.141
>date: 2001/09/14 10:36:52; author: ishii; state: Exp; lines: +0 -1
Lamar Owen writes:
> Attempting to build an initial RPMset here Will upload when I get a good
> build -- although I may have to release without the contrib tree packaged,
> due to build errors.
Did you get all the patches I sent you? These should have the contrib
tree covered. If you plan
Robert Dyas writes:
> One possible renaming / reorganization: (feedback encouraged!!!)
>
> change default account name postgres to pgsql
It's a little known secret, but there is no default account name!
"postgres" is simply what most people seem to choose (but by no means
all). The documentatio
Hannu Krosing writes:
> You could also consider the above as an IQ test ;)
The only problem is that computers have been shown to have an IQ of zero.
> I suggest that you do a writeup of yours, enumerating the rules for
> both internal (code and CVS tags) and external development, alpha,
> beta
On Sun, Oct 28, 2001 at 12:44:26PM +0100, Jean-Michel POURE wrote:
> I only want this query to work under Unicode:
> SELECT * FROM test WHERE source_content ILIKE '%accepté%'.
As I showed it works, if data in db is in UTF-8 and the query
string 'accepté' is in UTF8
> >* If client_encoding == ser
I only want this query to work under Unicode:
SELECT * FROM test WHERE source_content ILIKE '%accepté%'.
>* If client_encoding == server_encoding, the bytes are put into
> DB as-is - no conversion is done.
>
>So are you absolutely sure you have on client side UTF8 strings?
PostgreSQL is compile
On Sun, Oct 28, 2001 at 09:22:24AM +0100, Jean-Michel POURE wrote:
>
> I am running PostgreSQL 7.1.2 with UNICODE support in production.
> Maybe I miss something about UNICODE:
>
> CREATE TABLE "test" (
> "source_oid" serial,
> "source_timestamp" timestamp,
> "source_creation" date DEFAULT
>1) Did you compile PostgreSQL with --enable-locale
Yes.
>2) Did you set correct locale for postmaster (LANG=xxx)
Database was create using CREATE db WITH ENCODING='UNICODE'.
pgsql: \encoding returns UNICODE.
The db stores multiple languages (French, English, Japanese).
Why should I define a *s
On Sun, Oct 28, 2001 at 09:22:24AM +0100, Jean-Michel POURE wrote:
> Dear all,
>
> I am running PostgreSQL 7.1.2 with UNICODE support in production.
> Maybe I miss something about UNICODE:
> SELECT * FROM test WHERE source_content ILIKE '%accepté%' ---> returns
> nothing
> SELECT * FROM test WH
Dear all,
I am running PostgreSQL 7.1.2 with UNICODE support in production.
Maybe I miss something about UNICODE:
CREATE TABLE "test" (
"source_oid" serial,
"source_timestamp" timestamp,
"source_creation" date DEFAULT 'now',
"source_modification" date DEFAULT 'now',
"source_conten
23 matches
Mail list logo
