that; scroll back to half way
your result set now that you know what size it is.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,482bd864927661472788033!
--
Sent via pgsql-general mailing list (pgsql-general
^Dæã¿PF, which doesn't even seem a
valid UTF-8 sequence according to my quick checks.
what may be the solution.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,482930f1927662132392431!
--
Sent via pgsql-general
you to format the date to your liking too, just add a to_char
(loopdate, format string).
I know these were just a few examples of your troubles, but so far it
appears it's desirable to get rid of them for better code.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees
5812807
Email : [EMAIL PROTECTED]
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4818580a927661384610962!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
the NOT NULL column ID from the
sequence.
What sequence? You never told it you wanted one. A PRIMARY KEY
doesn't automatically add a sequence nor does a NOT NULL constraint,
the serial type does that but you defined the column as type int, not
as type serial.
Alban Hertroys
--
If you can't see
? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Alban Hertroys
--
If you can't see the forest
database? If so, why would you want to do that?
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,48008eed927663372713408!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
way.
What are you trying to fix that you don't just write SELECT
Column1,Column2 from MyTable ?
Postgres understands that fine, why do you want to quote those
identifiers? Maybe your application code is case-sensitive with
regards to column (and maybe table) names?
Regards,
Alban Hertroys
show us the table definition and its
indexes? What version of Pg is this?
It may be that your index on vals.datestamp doesn't fit into memory;
what are the relevant configuration parameters for your database?
Regards,
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees
On Apr 7, 2008, at 9:47 AM, David Wilson wrote:
On Mon, Apr 7, 2008 at 2:05 AM, Alban Hertroys
[EMAIL PROTECTED] wrote:
The databases estimates seem consistent with yours, so why is it
doing
this? Could you provide an EXPLAIN ANALYSE? It shows the actual
numbers next
to the estimates
for speed, of course).
Regards,
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,47f8b050927661534911704!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
indexes make your
database too slow, but you don't want a sequential scan now? What
kind of solution do you expect then? An oracle maybe?
You will need an index if this query is too slow for you, or you will
have to live with the slowness of this query. Pick one ;)
Regards,
Alban Hertroys
On Mar 21, 2008, at 5:58 PM, Anton Melser wrote:
Tom the Champion strikes again!
Cheers
Anton
I have the suspicion that his mother is named Lois, his father is
unknown and he has a sensitivity to Kryptonite. But that's just
speculation of course...
Alban Hertroys
--
If you can't see
similar to putting those id's in
a table and fetch them from your application - it's just moving the
work around.
Regards,
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,47df69e69781418010441!
--
Sent via pgsql
Regards,
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,47e019899786732118417!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
On Mar 19, 2008, at 2:35 AM, Tyler, Mark wrote:
Alban Hertroys wrote:
On Mar 18, 2008, at 3:58 AM, Tyler, Mark wrote:
I suggest rethinking your dislike of NOTIFY.
I have thought very hard about using NOTIFY for this but it has two
large problems (from my point of view). The first
be a nice addition
to this... Comments?
Regards,
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,47dba99b233093511810745!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
On Mar 13, 2008, at 2:00 AM, Berend Tober wrote:
Alban Hertroys wrote:
On Mar 11, 2008, at 10:28 PM, Tom Lane wrote:
An ON CONNECT trigger enforced by the database seems a bit scary
to me.
If it's broken, how you gonna get into the DB to fix it?
regards, tom lane
If creating
to reach the stored procedure that the trigger calls! A nice chicken
and egg problem, with some scope issues on the horizon...
Regards,
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,47d85f64233091819183316!
--
Sent
any reason that wouldn't be possible with SQL files. Added bonus, you
can use macros in your SQL, for things like environment paths (for
including other SQL files for example) etc.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest
to be used?
To fetch all rows unordered from a table the fastest method is a
sequential scan. An index scan would be slower, probably significantly.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,47d5748b233097069826464
that
Closest thing I can think of is defining a table that you insert a
record in as soon as you connect and put a trigger on that.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,47d5c63d233091216612506!
--
Sent via pgsql
in older PG releases that could lead to
duplicate rows (actually, to multiple versions of a row all being
seen as live). If you're not on the latest minor version of your
release series, update. regards, tom lane
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees
be 60 days, next month 61, this month next year
59, etc.
And I haven't even started on leap seconds and daylight saving time
yet...
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,47c69dd2233091191611641
' to the end
result.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,47c525af233091991417831!
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,47c1522f233091890169212!
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http
that lock for a very long time (should not
happen). You can check the pg_locks and pg_stat_activity tables for
that.
Regards,
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,47c159af233092392031086
.
what can i do? can you help me ?
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,47c15fde233095552171742!
---(end of broadcast)---
TIP 1: if posting/reading through
using these flags?
Thanks in advance.
Luca
That's like asking whether we'd still be able to speak English if you
configure Europe without Latin and Hebrew... Of course you can! ;)
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest
surprises, for example wrt
ordering (1, 2, 10 vs '1', '10', '2').
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,47b18f65233091858395181!
---(end of broadcast)---
TIP 1
-04-01'); was about 36s
Also, specifying dates like this without specifying their format is a
bad habit in my book. You're in trouble as soon as the date format
for your database changes (different system, for example). I suggest
you use to_date('2007-04-01', '-MM-DD') instead.
Alban
* and *column x* in
your mind.
Regards,
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,47af8f8e167321323610058!
---(end of broadcast)---
TIP 5: don't forget to increase
.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,47a4c3e7817485094119420!
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
of
queries
if the standard doesn't specify any obligation to convert the name ?
If you want to use case sensitive identifiers, then quote them! It's
not that hard. In your example above you're doing just that, so your
statement does not even apply ;)
Alban Hertroys
--
If you can't see the forest
skipped past them when there's
concurrent access.
There's still some risk for that if you order, but as you seem to
order on a sequence-generated column, updates aren't a problem for
you and inserts end up at the end anyway. But only if you order them.
Alban Hertroys
--
If you can't see
On Jan 15, 2008, at 3:03 PM, Ivan Sergio Borgonovo wrote:
On Tue, 15 Jan 2008 14:43:35 +0100
Alban Hertroys [EMAIL PROTECTED] wrote:
You need to scroll to the last row to find the size of the result
set, but after that it's pretty easy to return random rows by
scrolling to them (and marking
longer. That was on a dual 64-bit opteron
with 4GB RAM, iirc.
Of course a built-in statement would be preferable, I just felt like
pointing out that order by random() isn't necessarily the best
alternative ;)
Regards,
Alban Hertroys.
!DSPAM:737,478cb43e9496078213597
On Dec 13, 2007, at 14:12, John D. Burger wrote:
Alban Hertroys wrote:
The problem the OP is pointing out seems difficult to solve. A
sequence doesn't know about existing records with a possibly
higher number than the sequence is at.
This may be worked around by keeping a list of numbers
on
it are still quite fast (no need to look up child records separately,
for example).
--
Alban Hertroys
It's not a bug!
It's a six-legged feature!
!DSPAM:737,47610cc19659110557619!
---(end of broadcast
records with hand-
coded values for that column (unless you're sure you're using an
existing gap before the sequences current value).
Regards,
--
Alban Hertroys
Sometimes you wake up thinking:
Galileo was right, the world does turn
that was
just inserted.
Maybe there are statements in that procedure that attempt to remove
possible duplicates that also happen to match on the new record?
Regards,
--
Alban Hertroys
If you throw your hands up in the air,
how're
, ensure that
they are in the abbreviation list.
Isn't this just what the ABBR tag in html is for?
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World
)
Filter: (idxfti @@ '''dog'''::tsquery)
Total runtime: 0.163 ms
(6 rows)
I hope this helps.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World
PG 7.4, try a PG 8. There have been significant
performance improvements with IN lists in queries in the 8-series.
Regards,
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate
privileges to
install such a version).
So... How do I do this?
The system involved is some version of Debian Linux (2.6 kernel); are
there any packages for a Dutch stemmer maybe?
I'm in a bit of a hurry too, as we're on a tight deadline :(
Regards,
--
Alban Hertroys
[EMAIL PROTECTED
Alban Hertroys wrote:
The only odd thing is that to_tsvector('dutch', 'some dutch text') now
returns '|' for stop words...
For example:
select to_tsvector('nederlands', 'De beste stuurlui staan aan wal');
to_tsvector
, open source
object-relational
database management system, is now undergoing beta testing of the next
version of our software: PostgreSQL 8.2.
');
Oleg
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus
more efficient is somewhat sooner in favour
of the seq scan than on some other databases, because the index scan
needs to look at the actual record for visibility.
I pleed not guilty ;)
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
and probably only issued from
userland code.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World //
---(end of broadcast
, but only using them for a conditional update
(atomically I hope).
Oh, you mean:
UPDATE foo
SET ...
WHERE blah = 'blah'
AND NOT EXISTS (
SELECT 1 FROM baz WHERE foo.common_field = baz.common_field
)
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31
Albe Laurenz wrote:
Alban Hertroys wrote:
A. Kretschmer wrote:
Again: an index can't help! Because of MVCC: 'select count(*)'
without
WHERE-condition forces an seq. table-scan.
That has very little to do with MVCC.
[...] For that it makes no difference whether a seq
scan or an index scan
',
'MM/DD/'), INTERVAL '1 year').
That makes operators like OVERLAPS and BETWEEN available to your
queries, which may be convenient ;)
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
with any intervals
not dividable by a year).
Adding this additional column may justify putting the years (and their
durations) into their own table.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500
Nis Jørgensen wrote:
Alban Hertroys skrev:
Would something like
UPDATE master set m2 = master2.m2
FROM (
SELECT m2 +1
FROM master m
WHERE m.master_id = master.master_id
ORDER BY m2 DESC
) master2
work? I think it might be faster (and possibly cause less index
AND 1975
GROUP BY country_name, year
HAVING SUM(value) 0;
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World //
---(end of broadcast
+1
FROM master m
WHERE m.master_id = master.master_id
ORDER BY m2 DESC
) master2
work? I think it might be faster (and possibly cause less index bloat)
than doing two consequent updates.
Haven't tested this though...
--
Alban Hertroys
[EMAIL PROTECTED
I had to manipulate the headers a bit, as I hadn't noticed the message
that reached me first was from the newsgroup instead of the ML.
Nis Jørgensen wrote:
Alban Hertroys skrev:
As I said, I don't understand what you think it does. What you are doing
is similar to writing
SELECT m2
FROM
') - interval '1 month'
from my_temp_table;
Regards,
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World //
---(end of broadcast
James Williams wrote:
The box has 4 x Opterons, 4Gb RAM five 15k rpm disks, RAID 5. We
wanted fast query/lookup. We know we can get fast disk IO.
RAID 5 is usually adviced against here. It's not particularly fast or
safe, IIRC. Try searching the ML archives for RAID 5 ;)
--
Alban Hertroys
: (NOT (hashed subplan))
SubPlan
- Seq Scan on copy_mytable (cost=0.00..48.57 rows=1857 width=4)
(actual time=0.031..3.132 rows=1857 loops=1)
Total runtime: 10.291 ms
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
Martijn van Oosterhout wrote:
avg(*) is not valid, same for sum(*)
Doh!
Thanks.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World
Tom Lane wrote:
Alban Hertroys [EMAIL PROTECTED] writes:
Richard Huxton wrote:
AFAIK there are two variants of ANY()
1. sets
2. arrays
So you should be able to do:
... WHERE x = ANY( ARRAY[a, b, c] )
But then the documentation isn't entirely correct. It suggests that it
works similar
suffice, but I don't know the interval length in days before hand - and
thus not the middle point of the interval).
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your
index tmp_idx on table(number) where number != trim(number);
analyze table;
update table set number = trim(number) where number != trim(number);
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK
and never got it to work...
So, how do you use ANY with a fixed set of values (the way IN can)? And
can this be used to solve the OP's problem without using tricks like
summing NULL values?
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
Richard Huxton wrote:
Alban Hertroys wrote:
SELECT * FROM gdp WHERE NULL IS NOT ANY(y1970, y1971, y1972);
AFAIK there are two variants of ANY()
1. sets
2. arrays
So you should be able to do:
... WHERE x = ANY( ARRAY[a, b, c] )
But then the documentation isn't entirely correct
on this list a few
times) and may thus be exaggerating the problem.
Good luck!
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World //
---(end
values. Plus it translates directly to what we are requesting :)
Alban Hertroys wrote:
I thought of another solution (with only a few calculations of random())
that can be deployed in existing versions of PG, using a set-returning
function with a scrolling cursor that accepts the query string
Alban Hertroys wrote:
To follow up on my own post, I came up with a workable solution based on
scrolling cursors. The SP approach didn't work out for me, I didn't
manage to declare a cursor in PL/pgSQL that could be positioned
absolutely (maybe that's due to us still using PG 8.1.something
check that you're not connecting through the internet and
getting a DNS timeout?
Regards,
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World
On Aug 31, 2007, at 15:54, Martijn van Oosterhout wrote:
On Fri, Aug 31, 2007 at 02:42:18PM +0200, Alban Hertroys wrote:
Examples:
* random(maxrows) would return random rows from the resultset.
* median() would return the rows in the middle of the result set
(this
would require ordering
, not touching their position among other
records because they can't know how to compare them.
If you want certain behaviour from NULL values you'll need to specify
what you want or expect surprises ;)
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
On Sep 1, 2007, at 12:44, Alban Hertroys wrote:
It would be possible to write an aggregate that returns a single
random
value from a set. The algorithm is something like:
n = 1
v = null
for each row
if random() 1/n:
v = value of row
n = n + 1
return v
Doesn't this always return
On Sep 1, 2007, at 14:48, Phoenix Kiula wrote:
On 01/09/07, Alban Hertroys [EMAIL PROTECTED] wrote:
On Sep 1, 2007, at 11:46, Phoenix Kiula wrote:
.
..snip
However, there's a nested loop in there as the EXPLAIN ANALYZE shows
below. What is causing this nested loop?
It looks like
On Sep 1, 2007, at 14:44, Martijn van Oosterhout wrote:
On Sat, Sep 01, 2007 at 02:24:25PM +0200, Alban Hertroys wrote:
Oh, now I see... The first time guarantees that v has a value (as
random() 1/1), and after that there is a decreasing chance that a
new row gets re-assigned to v. That means
volunteer for at least looking into this, but I'm
working on three projects simultaneously already. Alas...
Regards,
Alban Hertroys.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
that have been changed, modified in table1 since the initial laod from
table1 into table2?
I think you could get smart having a few rules for insert/update/delete
on 'table' that keep track of what happens during your work on table2.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T
mechanisms.
In the worst case (all the above mechanisms fail), you have backups.
IMHO the problem is covered quite adequately. The operating system and
the hardware cover for the database, as they should; it's _their_ job.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0
FreeBSD should be added to that
list as well... They've been bench marking their threading support using
multi-threading in MySQL (not for the db, mind you - just for load ;),
and it performs really well.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0
Dave Page wrote:
Alban Hertroys wrote:
Joshua D. Drake wrote:
I agree with you on the multi-threaded. I think I will add a note
saying the the multi-threaded architecture is only advantageous on
Windows.
And Solaris.
I'm not entirely sure what makes multi-threading be advantageous
as
well try replicating to a newer release and swap them around once it's
done. I've seen that method of upgrading mentioned on this list a few times.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
of try {...}
catch (...) {...}, but it shouldn't be too hard to wrap it somehow for
exceptions in database code.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your
application will need twice as many
connections that way, though... In that case you shouldn't commit
records on the 'normal' connection before the audit records have been
committed I suppose?
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
else has noticed it.
I just finished going through my new mail since this morning, which
contained several fresh duplicates of messages I already read. So yes,
it happens to me too.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
(or rollback) if
you like the end result (or not). I believe the only exception to that
rule is CREATE DATABASE.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World
a sequential scan will be
faster. You probably want to become acquainted with autovacuum.
Another possibility is that most of your customers names start with
'eri', in which case a seq scan is actually faster... In that case you
should probably do something about your customer base ;)
Regards,
--
Alban
use a trigger (a before one maybe) instead of a rule.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World //
---(end of broadcast
an arbitraty
amount of time to complete. Maybe per user/database?
I suppose this number is only interesting on an uncongested database
server. Otherwise there will be queries passing that treshold that
normally wouldn't, because they have to wait for the real troublemakers
to finish.
--
Alban
database select version();
version
-
PostgreSQL 8.1.4 on x86_64-pc-linux-gnu, compiled by GCC cc (GCC) 3.3.5
(Debian 1:3.3.5-13)
(1 row)
--
Alban Hertroys
[EMAIL
Dave Page wrote:
Alban Hertroys wrote:
We have psql 8.2 clients on our workstations, while we still have pg 8.1
on our development and production servers. This causes problems like the
following:
database \d table
ERROR: column i.indisvalid does not exist
database
We can log
looking for NULLs it may be better
to query for col2 IS NULL.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World //
---(end of broadcast
Nis Jørgensen wrote:
Alban Hertroys skrev:
Presumably he wanted col2 like E'%N%'.
But doesn't \N mean NULL, or would the OP be looking for literal '\N'
strings in his data? Because if he's looking for NULLs it may be better
to query for col2 IS NULL.
My guess is that this string
.id
influences subquery (with t3), and the result influences back the
selection of t1 set?
Will greatly apreciate that.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
that way (ON
COMMIT DROP).
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World //
---(end of broadcast)---
TIP 9
intervals. Suffice to say, I'm a big
fan of the interval type.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World //
---(end of broadcast
by parent == node, for example.)
Obviously, I can do this with normal programming and loops, but it bugged
me a while if its at all possible doing this in one query.
Have a look at contrib/ltree ;)
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M
?
And then there are the vertex and pixel shaders...
It'd be kind of odd though, to order a big time database server with a
high-end gaming card in it :P
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK
you please send your messages as plain text? Your mail client is
doing something foul to the plain text alternative incorporated in the
multi-part message. It's almost unreadable this way.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
not matching are distinct or if you don't care about duplicates,
use UNION ALL instead of UNION.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World
) in the SELECT part of the statement to update the
statistics of the table being inserted into? Maybe they wouldn't be
entirely accurate, but it wouldn't it be more accurate than statistics
that say it's empty?
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0
901 - 1000 of 1292 matches
Mail list logo
