On Sun, Aug 21, 2005 at 06:35:22AM +0100, Aldor wrote:
> if you want to insert biiig data volumes try either using COPY instead
> of INSERT - it will run much much faster
And if for some reason you have to stick with inserts, group them into
transactions; it will perform much better than individu
Dear Lane, is that what you want?
CREATE TABLE network_nodes (
node_id SERIAL PRIMARY KEY,
node_name VARCHAR,
default_gateway_interface_id INTEGER
);
CREATE TABLE router_interfaces (
interface_id SERIAL PRIMARY KEY,
node_id INT REFERENCES network_nodes
);
CREATE VIEW current
I think the Enterprise DB folks are actively working it. I don't know what
their plans to release their work back to the community are.
Mail thread:
http://archives.postgresql.org/pgsql-general/2005-08/msg00582.php
Article: http://oetrends.com/news.php?action=view_record&idnum=428
Home: http://
Thanks again, Dmitri. I put a round() function around it, and got exactly
what I was looking for. Tried a cast earlier, but put it in the wrong place!
:-( Just noted that the manual (version 8.0, section 9.3) warns about
integer arithmetic and truncation of results, but fortunately there is a way
On Mon, 22 Aug 2005, Lane Van Ingen wrote:
> Hi, am trying to do a simple computation on two views, but for some reason
> the current_util_in computation always returns zero. All fields being used
> are integer.
>
> select a.if_id,
> a.in_count,
> a.time_incr,
> b.speed,
> ((a.t
I believe the problem is that the expression is being eavluated as an
integer, so it's rounded down before it's multiplied by 100;
A simple cast to float4 should help:
test=> select (589824 / ((240 * 255840) / 8) * 100);
?column?
--
0
(1 row)
test=> select (589824 / ((240 * 2558
Hi, am trying to do a simple computation on two views, but for some reason
the current_util_in computation always returns zero. All fields being used
are integer.
select a.if_id,
a.in_count,
a.time_incr,
b.speed,
((a.time_incr * b.speed) / 8) as possible_bytes,
(a.in_count /
am 22.08.2005, um 14:16:30 -0300 mailte Marc G. Fournier folgendes:
>
> In PostgreSQL, as everyone knows, a QUERY == a transaction, unless wrap'd
> in a BEGIN/END explicitly ... how does that work with a function? is there
> an implicit BEGIN/END around the whole transaction, or each QUERY wit
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> In PostgreSQL, as everyone knows, a QUERY == a transaction, unless wrap'd in a
> BEGIN/END explicitly ... how does that work with a function? is there an
> implicit BEGIN/END around the whole transaction, or each QUERY within the
> function itself
In PostgreSQL, as everyone knows, a QUERY == a transaction, unless wrap'd
in a BEGIN/END explicitly ... how does that work with a function? is
there an implicit BEGIN/END around the whole transaction, or each QUERY
within the function itself?
If the whole function (and all QUERYs inside of
On Mon, Aug 22, 2005 at 03:23:29AM -0700, Roger Tannous wrote:
> So, D'Arcy's solution, although described as 'unsatisfactory' (ref.:
> D'Arcy's message), seem to be the only solution.
>
> So I noticed I was trying to play the wise man, trying to do things in a
> better way, but nothing was found
On Mon, 22 Aug 2005 [EMAIL PROTECTED] wrote:
> Hi all,
>
> I've written a stored procedure but am having trouble calling it.
>
> The procedure name is called "insert_period" and I am calling using:
>
> SELECT
> insert_period(1::INTEGER,'2005-09-13'::DATE,'2005-09-15'::DATE,'unavailable_periods');
On Mon, Aug 22, 2005 at 03:17:02PM +0200, [EMAIL PROTECTED] wrote:
> ERROR: syntax error at or near "$1" at character 70
> QUERY: SELECT * FROM bookings WHERE (start_date, end_date) OVERLAPS (DATE $1
> - interval '1 day', DATE $2 + interval '1 day') AND property_id = $3 LIMIT 1
> CONTEXT: PL/pgSQL
Halley, here is a sample for you that might help; the purpose of this
function was to set an indicator of '1' or '0' (true or false) on a router
interface if the router interface ID was the same as the default gateway for
the Router node ID:
create view current_default_gateways_v (router_id, defau
Hi all,
I've written a stored procedure but am having trouble calling it.
The procedure name is called "insert_period" and I am calling using:
SELECT
insert_period(1::INTEGER,'2005-09-13'::DATE,'2005-09-15'::DATE,'unavailable_periods');
But am getting the error message:
-
ERROR: syntax e
So, D'Arcy's solution, although described as 'unsatisfactory' (ref.:
D'Arcy's message), seem to be the only solution.
So I noticed I was trying to play the wise man, trying to do things in a
better way, but nothing was found than D'Arcy's query:
SELECT pg_namespace.nspname, pg_class.relname,pg_at
16 matches
Mail list logo
