When comparing strings in perl you usually use the eq operator, not ==
e.g. if($cust_data->{hold} eq 't')
- Andrew
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Randall Perry
> Sent: Monday, 3 September 2001 10:01 AM
> To: [EMAIL PROTECTED
> | Its not a perception. Java is still a dog.
>
> Back it up or back out please.
>
> The most scalable and stable enterprise solutions out there are today
> running Java. In Java you actually get more time to concentrate on
> removing the real performance bottlenecks of your application.
Sequential scans are always going to be faster than using the index if a
large number of rows are going to be returned. Consider this: if you
are doing regular DELETEs, will there be that many rows selected for
deletion each time? Probably not, so Postgres will most likely use the
index for tho
> So far I haven't seen any real flames or insults thrown about
> yet - no MYsql will kill your puppy threads at all. There
> can be rigourous discussion without insults being thrown and
> so far that's all I've seen.
No, but it WILL kill your data, if the DB is big enough and has been in
us
> It wouldn't be a very bad idea for systems where mmap is
> noticeably faster than read/write using syscalls.
> Unfortunately on some of those systems mmap is broken for
> multiple processes mapping the same file...:)
Yeah, fair enough. But mmap works well on the more popular platforms
used
> We can always ask them to change things. The thing which
> strike me as wrong the most is the stability issue with
> PostgreSQL. I've only very rarely heard reports by anyone
> saying MySQL was more stable than PostgreSQL for them.
Yeah, saying mysql is more stable than postgres is a com
I prefer the way Notes (for example) handles it. All
records/documents/views are in read-only mode until the user indicates
they actually want to edit. They then exclusively lock that record for
editing, with optional timeouts (in case their workstation crashes or
whatever).
This turns out to
I believe if you throw decent hardware at it (the sort of hardware you
need to throw at 10GB database to make it perform well) then it is
definitely worth giving it a go.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Ivan Babikov
> Sent: Mond
Out of curiosity, whats wrong with vacuumdb -a? ("Vacuum all
databases.")
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of
> Stephen Davies
> Sent: Monday, 20 August 2001 7:33 PM
> To: [EMAIL PROTECTED]
> Subject: [GENERAL] Finding database nam
> I have found (and confirmed by studying the PostgreSQL
> source) that to reliably insert arbitrary binary data into a
> bytea column there are only 3 characters which need to be
> escaped: \000, \047 ( ' ), \134 ( \ ). Here's the PHP
> function that I've been using:
Postgresl, in treatin
> > Correct me if I'm wrong, but the only thing "lztext" can't store is
> > NULLs, which could escaped somehow with other (rare) characters.
> > Still overhead, but you shouldn't be storing large pieces of binary
> > data this way, I think.
>
> Here is not a problem with storing binary data
> Yes, but good is encode binary data (image) to same ascii safe
> encoding like base64, else you will have problem in INSERT/UPDATE
> queries.
Correct me if I'm wrong, but the only thing "lztext" can't store is
NULLs, which could escaped somehow with other (rare) characters. Still
overhead,
> Any suggestion on how to prepare for the next upgrade would be
> appreciated.
I think it has to be said that if you want decent performance on excessively
large (50GB+) databases, you're going to need excessively good hardware to
operate it on. Buy a 3ware IDE RAID controller (www.hypermicro.
If you're asking how to get XML data into PostgreSQL, for perl users:
Matt Sergeant's DBIx::XML_RDB module looks handy. (I think it just got
added to the FreeBSD ports collection too).
http://www.xml.com/pub/a/2000/12/13/perlxmldb.html
Or use any XML parser module (XML::Simple!) and pump the d
> Puzzling
I am pretty sure there are some bugs in v7.1.x PL/PGSQL, they are difficult
to produce and nail down though. A few of my functions that were working
fine in v7.0.x broke completely. I am doing more testing and will submit
some bug reports...
- Andrew
-
> I believe I can work around this problem using cursors (although I
> don't know how well DBD::Pg copes with cursors). However, that
> doesn't seem right -- cursors should be needed to fetch a large query
> without having it all in memory at once...
Actually, I think thats why cursors were inv
> > That's an excellent point, especially considering that *sequences* use
> > an integer to hold their max_value, which is by default 2,147,483,647.
> > You cannot go larger than that, either. I guess it's constrained to be
> > positive. So OIDs give you more potential unique values than seque
> My mistake! ;-)
> I remember wondering who would ever need more that the 16K that
> the Sinclair Spectrum could give you!
To go back to my original point about putting things in perspective -
increasing this by 2^32 would give you 68 terabytes of RAM. But if we can
get rid of oid's altogether
> Simply waiting for 64bit numbers is rather inelegant and also
> presumes usage
> parameters for the database... remember Bill Gates saying that he couldn't
> foresee any usage for more than 64MB of RAM?
I've heard this before and I just don't agree. 64MB ram, perhaps, but who
is going to need
> > 1. How do you remove one of two identical rows
> > from a pgsql table ?
>
> DELETE FROM t1 WHERE wil do the stuff for you. If you don't know
> the value into the duplicate field just export the database with pg_dump
> create
> a unique index onto this field and reimport all your data. Du
> I usually prefer the following trick for preventing long locking
> times. On every
> table I define a timestamp field which is updated every time the record is
> written to the database. If a user edits a record (without
> locking) and commit his changes
> the timestamp is returned from the cli
t; result are calculated). I've tried to define
> a view, but it didn't worked (
> create view distValues as select distinct ...
> but views doesn't support distinct clause)...
SELECT COUNT(DISTINCT field_name) FROM table_name;
Works for me in v7.
Regards,
Andrew Snow
[EMAIL PROTECTED]
> Is this necessarily a good solution? If you use 64-bit OIDs, some joker
> will just hook up a several-terra-byte disk array to his machine, try to
> store the location of every molecule in the universe and break it.
If you have to have OIDs at all, its a lot better than a 32 bit number. I
th
> When we are sure all platforms support 64-bit int's, we will move in
> that direction.
Sorry if this is a stupid question, but couldn't you fairly easily make it
an option at compile time? To use either 32 or 64 bit OID's.
(And, less importantly, for sequences)
- Andrew
> It feels like there should be some *really* obvious answer to this
> question, and I'll find myself whacking my forehead in self-abasement
> and out of sheer relief to have found the answer to a problem that
> should not have bothered me in the first place since the answer is too
> self-evident
On Fri, 14 Apr 2000, Thomas wrote:
> For large 24x7 installations, it's impossible to vacuum nightly because when
> postgresql is vacuuming the table is locked up, to the end-user the database
> has already hung.
That's right. I complained about this in a discussion with a Postgresql
developer
On Fri, 14 Apr 2000, Thomas wrote:
> For large 24x7 installations, it's impossible to vacuum nightly because when
> postgresql is vacuuming the table is locked up, to the end-user the database
> has already hung.
That's right. I complained about this in a discussion with a Postgresql
developer,
I'm using PostgreSQL 6.5.3 on a FreeBSD 3.4-STABLE box (all you linux
postgresql users out there, switch to freebsd already!).
I had created a View A, based on an existing View B. When I dropped View B
and re-created it one day, the View A did not get deleted, but as soon I
went to use A again
28 matches
Mail list logo
