I've been reading up on what Informix and Oracle provide in the way of
object support.
In particular I noticed that in Informix when you SELECT on a table it
by default includes all the objects of sub-classes. In other words the
"*" is postgres terms is always there by default. If you just want
"Gunnar Ingvi Thorisson" [EMAIL PROTECTED] writes:
I´ve a table with about 142000 rows like shown below and I want to
set field "divis" to "unknown" by executing following update command:
update ipacct set divis = 'unknown';
However this seems to take hours,
Well, updating 142000 rows is
Chris Bitmead [EMAIL PROTECTED] writes:
To me this is a much better idea. In any proper OO application you would
be using the "*" in postgres 99% of the time - that being the whole
point of OO. Does any consideration want to be given to making the same
change while there's not too many people
[PostgreSQL 6.5.0 on i586-pc-linux-gnu, compiled by gcc egcs-2.91.66]
table opset_steps
(name text, id int2, ver int2) [1400 rows]
non-unique index is on (id, ver)
table run_opsets
(status int2, id int2, ver int2, run_id int2, seq int2) [17000 rows]
pkey is (id, seq),
If there was enuff interest (I'm not siding one way or the other) you could
add in a global setting to change the default.
I was also curious as to why these msgs are cross posted in 3 different
groups...
-Original Message-
From: Tom Lane [EMAIL PROTECTED]
To: Chris Bitmead [EMAIL
Hi
I am trying to figure out how I can create an entry if one does not
exist when attempting an update.
This kind of what I want to do :
if (select "User-Name","Realm" from details;) {
update details set "Time-Used" = old."Time-Used" +
new."Time-Used";
} else {
insert into
George Young [EMAIL PROTECTED] writes:
Yes! PGOPTIONS="-fh" made the query time go from 16 seconds to 2 seconds!
Is this a safe thing to leave on permanently, or is there some way to set
PGOPTIONS for just this query?
I wouldn't recommend leaving it on as a long-term solution, because
you're
Tom Lane wrote:
The right long-term solution is to figure out why the system is
misestimating the relative costs of the two plans, and fix the cost
estimates. (The system is estimating that the mergejoin is about 4x
slower than hash; if it's really 8x faster, there is something pretty
Mark Wilson wrote:
Last night I reformatted the disk, create a new filesystem and restored
the last good full backup (from about a week ago) hoping I could get a
^^^
What did you use for backup ?
pg_dump/copy or you cp-ed datafiles to another place ?
version of the
