of
the flags can be grouped together?
--
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 6
whether it is inclusive or
exclusive (the latter apparently).
How to make overlaps to return correct result?
select 1 where ('2006-10-30'::date, '-12-31'::date) OVERLAPS
('2006-10-16'::DATE, '2006-10-31':: DATE);
?column?
--
1
(1 row)
--
Alban Hertroys
[EMAIL PROTECTED
the boundary dates?
Like so;
select 1 where ('2006-10-31'::date -1, '-12-31'::date +1) OVERLAPS
('2006-10-16'::DATE -1, '2006-10-31':: DATE +1)
Regards,
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus
this, but I'd like to be sure.
IF previous IS NOT NULL
THEN
-- Compare previous and current column values
END IF
previous := current;
END LOOP;
END;
Thanks in advance,
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F
count comments, if not, i
consists of
last line of my SELECT command == AND articles.validity_period_end now()
Line 17 is your first (faulty) assignment from myrec. Line 1 is the line
containing 'DECLARE'.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31
variable an alias though:
DECLARE
TypeArt ALIAS FOR TypeOfArticle;
You could also move the assignment into the body of the function.
Although I wonder why you don't just use the IN parameter.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0
(TypeOfArticle varchar)
RETURNS SETOF public.active_articles AS
$body$
DECLARE
TypeArt VARCHAR := $1;
rec RECORD;
res active_articles;
/**/
BEGIN
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
') AND (TG_WHEN = 'BEFORE')) THEN
IF (SELECT COUNT(*) FROM text(TG_RELNAME)) 4
You'll want to DECLARE an integer variable and use SELECT INTO with it.
And EXECUTE, as mentioned.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0
it (at least I
couldn't make it to). To load 1,5M rows (~230MB of INSERT statements),
INSERT statements? You dumped with the -d flag, didn't you? Otherwise
you'd have seen COPY statements instead, which are much faster (and of
which much fewer are necessary, usually).
--
Alban Hertroys
[EMAIL PROTECTED
), but that's something beyond our control.
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
.
--
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 5: don't forget to increase your
-data, like the version of PostgreSQL, is
probably required as well.
The current statistics contain some of this information, but from
reading this list I know that that's rarely enough information to
determine an error made by the planner.
Regards,
--
Alban Hertroys
[EMAIL PROTECTED
problem (the transaction is gone after the
first page).
I believe, as a result of this, it is not uncommon to pass the primary
key id's of all results on in a hidden field, so they are available for
quick querying on proceeding pages.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T
: ON DELETE CASCADE;
UPDATE x SET x_id = DEFAULT;
COMMIT; -- after you checked the results
How to determine whether a table has a PK was already explained.
Regards,
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
function and putting
that in a recognizable place in your exception text. Not pretty, but it
should do the job.
--
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
structures, and probably makes your problem much
simpler.
--
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
Mail from this ML doesn't seem to arrive at our office anymore (you
haven't been silent for 4 days, have you?). Hence a small test.
Sorry for the inconvenience.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
Kai Hessing wrote:
Alban Hertroys wrote:
SELECT s.sid FROM stud s, stud_vera v WHERE s.sid = v.sid AND v.veraid =
34 AND s.sid NOT IN ( SELECT sid FROM stud_vera WHERE veraid = 2 );
I'm pretty sure it's not a deadlock. It probably takes very long for
some reason; maybe an explain of that query
is available, maybe wrapping your DDL statements in a pl/pgsql
SP will work. pl/pgsql has exceptions...
I haven't tried this, but I expect it will work.
--
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
[EMAIL PROTECTED] wrote:
On the one hand I like how the schema scripts fail when there is a
single problem with a DDL statement.
Your mail address bounces. Unfortunately my Trash is broken, so I can't
show you the error; I was a bit quick deleting it.
--
Alban Hertroys
[EMAIL PROTECTED
thing; something went wrong, queries after the
error may very well depend on that data - you can't rely on the current
state. And it's what the SQL specs say too, of course...
[1] I'm not trying to imply that what PostgreSQL does is (in general).
--
Alban Hertroys
[EMAIL PROTECTED
the trigger.
An alternative approach would be to use a permanent table, fill it
within your transaction and trunk it eventually. To other transactions
there'll never be any data in it, and you lose the overhead of creating
and dropping the table (replacing it by trunking...).
--
Alban
and update it to the highest
value in use if it's too low. You should only need to do that once.
--
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
too.
It is not much harder to say We currently don't have the resources to
look into that, if you could be so kind to experiment a bit and see if
you can get it to work
It might even invite other readers of this ML to look into it instead.
Regards,
--
Alban Hertroys
[EMAIL PROTECTED
your problem by creating 2 unique constraints:
CREATE UNIQUE INDEX idx1 ON table (col1, col2) WHERE col2 IS NOT NULL;
CREATE UNIQUE INDEX idx2 ON table (col1) WHERE col2 IS NULL;
Regards,
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
not to put our running
databases at risk.
As an alternative approach, wouldn't dropping and recreating the public
schema be a nice alternative? And in that case, what would be the right
CREATE SCHEMA public command? I don't feel like messing this up ;)
Regards,
--
Alban Hertroys
[EMAIL PROTECTED
Berend Tober wrote:
On Wed, Sep 13, 2006 at 10:56:41AM +0200, Alban Hertroys wrote:
I'm humble (or naive) enough to admit that I've used the approach
outlined there by Josh Berkus, and it worked fine. More than once, even.
I'm quite certain that approach can be made more bullet-proof
of SELECT COUNT(*) FROM
x LEFT OUTER JOIN y USING (id) isn't relevant for the result and skip
the join?
Attached are the explain plans for both versions and a few variations
(TB wraps it if I paste).
Regards,
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0
Martijn van Oosterhout wrote:
On Mon, Sep 11, 2006 at 11:58:56AM +0200, Alban Hertroys wrote:
Hi,
I was tuning a join on a few tables for a SELECT COUNT(*) query, when I
realized that the content of the second table didn't actually matter to
the count. So, I figured a LEFT OUTER JOIN would
.
--
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 6: explain analyze is your friend
exceeding 2^32.
Or are you short on caffeine perhaps? ;)
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
://cwiki.apache.org/CAYDOC/primary-key-generation.html it seems
possible to use database sequences instead of Cayenne-generated ones:
... Generation mechanism depends on the DbAdapter used and can be
customized by users by subclassing one of the included adapters.
Regards,
--
Alban Hertroys
[EMAIL
to timestamp.
--
Alban Hertroys
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
' + timestamp '1900-01-01 00:00:00'
There's also 'EPOCH', which is shorter and more explicit.
timestamp 'EPOCH + timestamp * interval '1 second'
--
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
. Benefit for everyone involved; and they lived long
ever after.
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
Michael Glaesemann wrote:
Note that epoch does not mean 1900-01-01 00:00:00.
Indeed! Where did this 1900 sneak in? Aren't timestamps usually based on
epoch?
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
in different
connections, and on the same connection after rolling back the
transaction which created the first table... so I don't know what to try
to trigger this.
Any ideas what's the problem ?
Are you sure that you're not re-using an existing connection from a pool?
--
Alban Hertroys
[EMAIL
solutions aren't mentioned
(the OP found a workaround though). They may have never been found...
I suppose if you'd check pg_type there is a record containing 'temp_report'?
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
observation_date (which'd be interesting
when using cursors) or something along those lines. Hmm... Now I'm all
curious; an EXPLAIN'd be interesting...
Sorry for the mostly useless post :P
Regards,
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
basically is a UNION
over all the tables involved). You may want to check the archives.
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
UNION as opposed to UNION ALL (as other
people already mentioned).
To merge duplicate results (one from either subquery) the database
sorts[1] the results. To do that, it needs to compare with other records
- hence the extra subquery, and probably the added 50ms as well.
Regards,
--
Alban
Tom Lane wrote:
Alban Hertroys [EMAIL PROTECTED] writes:
I'm confused too. Would it be possible for you to send me a dump of
your database?
Attached is a cleaned out database, the full schema is included, but
only the relevant tables contain any data.
Thanks. After digging through
mm_insrel_dnumber_dir_not_one_idx | 899 |323628
mm_insrel_table_pkey | 1237 |323628
mm_insrel_relation_idx| 1849 |323628
mm_insrel_full_idx| 1260 |323628
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
index.
We also figured we could use some triggers to generate data that could
improve query performance (moving conversions from SELECT-time to
INSERT-time), but unfortunately MMBase's caches are in the way there.
Regards, Alban.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T
the primary key index (likely), or - if we remove even that one - a
sequential scan... Experimenting will answer that.
Thanks for your answers so far, at least now we know what's going on.
Regards,
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
Alban Hertroys wrote:
Tom Lane wrote:
I'm thinking that removing the indexes it's erroneously using now could
help performance, as it can no longer use that index. It may however
pick the primary key index (likely), or - if we remove even that one - a
sequential scan... Experimenting
Tom Lane wrote:
Alban Hertroys [EMAIL PROTECTED] writes:
zorgweb_solaris= select * from pg_stats where attname = 'number' and
tablename IN ('mm_insrel_table', 'mm_product_table', 'mm_object');
tablename | mm_product_table
histogram_bounds
Tom Lane wrote:
Alban Hertroys [EMAIL PROTECTED] writes:
However, mm_product.number always matches either mm_insrel.snumber or
mm_insrel.dnumber (source and destination respectively). The other way
around this isn't the case; then snumber and dnumber match number-fields
in other tables
Tom Lane wrote:
Alban Hertroys [EMAIL PROTECTED] writes:
tablename | mm_product_table
attname | number
histogram_bounds | {2930,3244,3558,3872,4186,4500,4814,5128,5442,5756,6070}
tablename | mm_insrel_table
attname | snumber
histogram_bounds
,
mm_product_table.free_care_choice, mm_product_table.export_to_rivm,
mm_product_table.export_to_kwiz, mm_product_table.export_to_ind
epender, mm_product_table.show_in_frontend, mm_product_table.path,
mm_product_table.type_notes
FROM mm_product_table
JOIN mm_object USING (number);
--
Alban Hertroys
[EMAIL PROTECTED
-datetime.html
--
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 2: Don't 'kill -9
to remove all those double-quotes. They make your
table and column names case sensitive. You'd need to quote these in your
queries as well, if you stay with what pgadmin (apparently) created.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
[EMAIL PROTECTED] wrote:
I'd like to truncate varchar field befor insert and update.
Any example of trigger to perform this action?
For something as simple as that a RULE using the trim(text) function
should work well. If that's what you're looking for.
--
Alban Hertroys
[EMAIL PROTECTED
) cause a type cast
on the column value of every indexed row, which does slow down things
significantly. I believe this was solved in PostgreSQL 8.something.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
second to finish.
--
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 5: don't forget
locked yourself out...
--
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 1
within an XSLT sheet, but that seems unlikely. Can't hurt to ask though ;)
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
--+--
Vasja| dcde745cc304742e26d62e683a9ecb0a
(1 row)
Why don't you store the hashed value instead?
--
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
WHERE auction_id = 1234
GROUP BY user_id
HAVING created_at = MAX(created_at);
You could also use a subselect with an order by created_at DESC limit 1
over each users bids.
Regards,
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
, according to my colleague here this wasn't possible until now
(partially!) in Oracle 10. Meaning it's not common-place even among
enterprise db's.
--
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
.
--
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 4: Have you searched our list
,
--
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 1: if posting/reading through
a sequence. It's its purpose.
Now I may have missed something, I didn't follow this thread.
[1] Unless you manage to make it wrap around after 2^32 (or 2^64?) calls
of nextval. But that's quite unlikely.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
of 3.31 minutes) does it take so
long?
Why do you ask us, instead of the database? EXPLAIN ANALYZE is your (and
our) friend. Without that we can only guess what's slowing down your query.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
Jim Nasby wrote:
On Jun 19, 2006, at 7:00 AM, Alban Hertroys wrote:
Now all we need to do is getting MMBase to do its queries like this :P
Probably a better bet would be going to 8.1 and using constraint
elimination.
I searched the documentation, google and wikipedia for constraint
Alban Hertroys wrote:
Jim Nasby wrote:
Probably a better bet would be going to 8.1 and using constraint
elimination.
Maybe you mean constraint exclusion?
If so, is that going to help excluding partitions (basically the same
thing, it seems) from a query based on an ORDER BY and a LIMIT
query... Well, I said it complicates things...
--
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
is getting MMBase to do its queries like this :P
Thanks a bunch for setting me on the right track.
--
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
Alban Hertroys wrote:
Hi all,
We're using some 3rd party product that uses inheritence, and the
following query is rather slow on PostgreSQL 7.4.7 (debian stable). Any
suggestions how to speed it up?
We really need this solved. Isn't anybody able to shed some light on
this? Is it possible
| integer | not null
owner | text| not null
Indexes:
mm_object_pkey primary key, btree (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 Enschede
// Integrate Your World
Alban Hertroys wrote:
Hi all,
We're using some 3rd party product that uses inheritence, and the
following query is rather slow on PostgreSQL 7.4.7 (debian stable). Any
suggestions how to speed it up?
A few more datapoints:
- Database was vacuum full analyzed just before the query
[EMAIL PROTECTED] wrote:
Why isn't
./010.pgsql.sh start
./010.pgsql.sh initdb
working? Am I doing something wrong?
You need to add postgresql_enable=YES to your /etc/rc.conf.
This changed in FreeBSD 6.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0
[EMAIL PROTECTED] wrote:
I did that and it worked. Was just wondering what's wrong with 010...
Nothing at all ;)
--
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
client to use UTF-8 or alter your database
to use LATIN1.
--
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
Tom Lane wrote:
Alban Hertroys [EMAIL PROTECTED] writes:
I can see some problems there, as both value and range matter; it'd be
similar to determining the uniqueness of an area in a rectangle (though
1 dimensional only, of course).
Except that what you want is to forbid overlap, not forbid
Jorge Godoy wrote:
Em Quarta 24 Maio 2006 13:06, Alban Hertroys escreveu:
Jorge Godoy wrote:
That's not what I showed above. What I meant was:
CREATE TABLE base_schema.sample ();
CREATE TABLE client1_schema.sample () INHERITS FROM base_schema.sample;
ALTER TABLE client1_schema.sample
Tom Lane wrote:
Alban Hertroys [EMAIL PROTECTED] writes:
With what I have in mind, both overlap and equality would violate the
unique constraint. I don't quite see why someone'd want to forbid
overlap but to allow equality; isn't not allowing equality the whole
point of a unique constraint
Tom Lane wrote:
Alban Hertroys [EMAIL PROTECTED] writes:
I'd say unique constraint violation right here (provided there's a
unique constraint on this column, of course). The order in which these
are inserted/updated doesn't seem to matter either. I'm afraid I'm still
missing the point
timespans.
When encountering this problem I usually wonder why there isn't a data
type that can store a timestamp and can be used to create a UNIQUE INDEX
over it's values. That'd be wonderful.
Well, maybe one day I'll actually have time to create one...
--
Alban Hertroys
[EMAIL PROTECTED
of inheritence? You'd need your
company_id back, but adding new companies or modifying table definitions
could be a lot easier (as long as you don't need to update all of your
views...).
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
Kenneth Downs wrote:
Alban Hertroys wrote:
When encountering this problem I usually wonder why there isn't a data
type that can store a timestamp and can be used to create a UNIQUE
INDEX over it's values. That'd be wonderful.
Well, maybe one day I'll actually have time to create one...
I
Jorge Godoy wrote:
Em Quarta 24 Maio 2006 06:09, Alban Hertroys escreveu:
What about using updatable views instead of inheritence? You'd need your
company_id back, but adding new companies or modifying table definitions
could be a lot easier (as long as you don't need to update all of your
/output functions for composite
types I guess, because those can only be codec in C AFAIK.
That's what I was refering to. Apparently I didn't make myself very clear.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
Kenneth Downs wrote:
Alban Hertroys wrote:
The approach I tried was to have a range or interval type. You
place a column into a table named resv_date or whatever and it would
expand the definition into two columns, you'd get resv_date_beg and
resv_date_end. If you declared the resv_date
Jorge Godoy wrote:
Em Quarta 24 Maio 2006 11:48, Alban Hertroys escreveu:
Jorge Godoy wrote:
Some things are really important here:
- performance for operations on an individual company --- it has to be
as fast as possible because this might be used by my client's clients
mathematical way
to determine this on a given data set?
Being able to provide these numbers to you guys would then help in
determining what a good default statistics size is, and maybe even for
determining an algorithm to adjust statistics sizes on the fly...
Regards,
--
Alban Hertroys
[EMAIL PROTECTED
)
and then on 8.1.3. Both show this behaviour.
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
Berend Tober wrote:
Alban Hertroys wrote:
So, One and a half hour in the future is actually 17 days ago?
Interesting... Either I am doing something wrong, or postgres is, I have
my suspicions ;)
good-natured sarcasmYour suspicions are correct that you are doing, or
rather, understanding
romeo midhun wrote:
hi friends,
Why the 'oid' column reference doesn't work with postgresql 9.x?
Hiya, time traveller. You ended up in the wrong year; PostgreSQL 9
doesn't exist yet.
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
) can do a
lot more sometimes.
It looks like something like that shouldn't be too hard to write...
Maybe it even does exist already. Personally I'd prefer a command line
tool ;)
It would help if you can pipe the output of explain analyze to an
external tool from within psql.
Regards,
--
Alban
a couple million seperate INSERTs,
and it gives you the opportunity to fix mistakes if you issue the above
command inside a transaction.
--
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
in the subquery
instead of the constant value 1. EXPLAIN ANALYZE will tell ;)
--
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
'.
Is there some easy way to query such intervals in a way that can be
reliably split up?
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
(a, b, c, id) VALUES (new.a, new.b, new.a + new.b, new.id);
But as others suggested, a view is probably the better way to go.
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
result set.
You could order by column 2 if you want to order on the results on
your aggregate:
Select a, aggregate(b)
from c
group by a
order by a,2
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
here. I'm not directly involved with
PostgreSQL.
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
() function would give the same results.
You'll want this instead:
SQL select (35.0/124.0)::numeric;
numeric
0.28225806451612903226
Regards,
--
Alban Hertroys
[EMAIL PROTECTED]
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I
there yet.
Mind though that I rarely use Windows; I use it almost exclusively for
playing games. I am biased ;)
--
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
Stephan Szabo wrote:
On Fri, 21 Apr 2006, Alban Hertroys wrote:
Stephan Szabo wrote:
SQL CREATE TABLE ltree_test (path ltree PRIMARY KEY REFERENCES
ltree_test(path));
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
ltree_test_pkey for table ltree_test
CREATE TABLE
SQL INSERT
it be made to know that somehow (functional foreign keys or
something - maybe using ltree_isparent(ltree, ltree))?
I can determine things like this with a few experiments, but I want to
know the right way to work with ltrees and referential integrity. How
do people use this?
--
Alban Hertroys
1101 - 1200 of 1292 matches
Mail list logo
