2008/7/20 Milan Oparnica [EMAIL PROTECTED]:
Pavel wrote:
try to write prototype and show advantages...
Prototype of what, implementation into Postgre or just efficiency of
PRESISTANT PREPARE idea ?
really prototype
...but I see some disadvatage
too. Mainly you have to manage some
On Tue, Jul 22, 2008 at 12:43 AM, Pavel Stehule [EMAIL PROTECTED] wrote:
2008/7/20 Milan Oparnica [EMAIL PROTECTED]:
Is it solved in MySQL or they've just tried ?
http://www.mysqlperformanceblog.com/2006/08/02/mysql-prepared-statements/
Wow, the discussion at the bottom of that page made me
Hello
Assume I have a table like
create table foo (
id serial,
date foodate,
primary key(id)
);
with 2 tupls
insert into foo(foodate) values('2008-07-07'); --id = 1
insert into foo(foodate) values('2008-07-04'); -- id = 2
What I need is to select the nearest tupl by a given date and I do
am Tue, dem 22.07.2008, um 10:42:56 +0200 mailte Christian Kindler folgendes:
Hello
Assume I have a table like
create table foo (
id serial,
date foodate,
primary key(id)
);
with 2 tupls
insert into foo(foodate) values('2008-07-07'); --id = 1
insert into foo(foodate)
Hi,
is there a way to speedup group by queries with an index?
In particular if I have a table like this:
CREATE TABLE data
(
id1 integer,
id2 integer,
somedata character varying,
ts timestamp with time zone
);
where continously data is logged about id1 and id2 into somedata,
am Tue, dem 22.07.2008, um 13:18:30 +0200 mailte Patrick Scharrenberg
folgendes:
Hi,
is there a way to speedup group by queries with an index?
In particular if I have a table like this:
CREATE TABLE data
(
id1 integer,
id2 integer,
somedata character varying,
ts
Thanks for your solution - it works (with some slightly adaptions) - but its a
bit slow ...
select * from (
(select id, foodate-'2008-07-06'::date as difference from foo where foodate
'2008-07-06'::date
-- forgot a
order by foodate limit 1)
union
(select id,
Hi list,
I just enabled log duration in a 8.3.1 database and got puzzling
information.
I have a daemon shell-script run every 10 seconds the following:
psql -c select f_tasador();
The 'f_tasador' procedure is quite fast. As per log output I can see the
procedure completes its execution
On Tue, 22 Jul 2008, Fernando Hevia wrote:
I just enabled log duration in a 8.3.1 database and got puzzling
information.
I have a daemon shell-script run every 10 seconds the following:
psql -c select f_tasador();
The 'f_tasador' procedure is quite fast. As per log output I can see the
On Tue, Jul 22, 2008 at 12:10 PM, Fernando Hevia [EMAIL PROTECTED] wrote:
Nevertheless in the LOG
duration entry it shows a statement duration of over 36 secs.
¿What is going on? ¿Where come those 36 seconds from?
2008-07-22 15:52:37 ART|postgres| LOG: duration: 38.154 ms
:o) You might be
De: Richard Broersma [mailto:[EMAIL PROTECTED]
Enviado el: Martes, 22 de Julio de 2008 17:19
2008-07-22 15:52:37 ART|postgres| LOG: duration: 38.154 ms
:o) You might be encountering a bit of parallax. This shows
both 38 and 36 *milliseconds*.
That's embarrasing... I mistook the
Fernando Hevia [EMAIL PROTECTED] writes:
The 'f_tasador' procedure is quite fast. As per log output I can see the
procedure completes its execution within one second. Nevertheless in the LOG
duration entry it shows a statement duration of over 36 secs.
It says milliseconds, not seconds.
At 09:20 AM 7/22/2008, [EMAIL PROTECTED] wrote:
Date: Tue, 22 Jul 2008 13:27:24 +0200
From: A. Kretschmer [EMAIL PROTECTED]
To: pgsql-sql@postgresql.org
Subject: Re: index for group by
Message-ID: [EMAIL PROTECTED]
am Tue, dem 22.07.2008, um 13:18:30 +0200 mailte Patrick Scharrenberg
On 20/07/08 22:16, Milan Oparnica wrote:
Try to write following simple scenario:
a. Data is retrieved from two tables in INNER JOIN
b. I don't need all fields, but just some of them from both tables
Lets call tables Customers and Orders.
Definition of tables are:
Customers (CustomID
14 matches
Mail list logo
