On Thu, 7 Nov 2002, Achilleus Mantzios wrote:
> On Wed, 6 Nov 2002, Stephan Szabo wrote:
>
> > On Wed, 6 Nov 2002, Achilleus Mantzios wrote:
> >
> > >
> > > Hi i think a hit a major problem on 7.2.1.
> > > I run 3 systems with postgresql 7.2.1.
> > > Its a redhat 7.1 for development, a redhat 7.3
On Wed, 6 Nov 2002, Stephan Szabo wrote:
> On Wed, 6 Nov 2002, Achilleus Mantzios wrote:
>
> >
> > Hi i think a hit a major problem on 7.2.1.
> > I run 3 systems with postgresql 7.2.1.
> > Its a redhat 7.1 for development, a redhat 7.3 for production
> > and a FreeBSD 4.6.1RC2 for testing.
> >
> >
>> 2) I am looking for an elegant way of copying a rowtype variable:
>>
>> eg.
>>
>> DECLARE
>> current_row orf%ROWTYPE;
>> previous_row orf%ROWTYPE;
>> BEGIN
>>
>> LOOP
>> -- use cursors or FOR SELECT to get values into current_row
>> -- now try this:
>>
>> previous_row = current_row;
>>
That looks really promising as a possibility, however I think you intended
to add a group by clause.
Terry Fielder
Network Engineer
Great Gulf Homes / Ashton Woods Homes
[EMAIL PROTECTED]
> -Original Message-
> From: Masaru Sugawara [mailto:rk73@;sea.plala.or.jp]
> Sent: Wednesday, Nov
On Thu, 07 Nov 2002 01:44:25 +0900
I wrote <[EMAIL PROTECTED]> wrote:
> On Wed, 6 Nov 2002 09:01:49 -0500
> <[EMAIL PROTECTED]> wrote:
>
> > If anyone can see a way to do a group by to do this, then I will be happy to
> > hear about it, because currently the resultset has to do a separate
> > (s
On Wed, 6 Nov 2002 [EMAIL PROTECTED] wrote:
> Actually, come to think of it, just the implementation of re-querying a
> temporary table could alone significantly improve performance, because the
> temp table would:
> a) have fewer records to scan on the subselects
> b) not require any joins
Yeah,
On Wed, 6 Nov 2002 09:01:49 -0500
<[EMAIL PROTECTED]> wrote:
> If anyone can see a way to do a group by to do this, then I will be happy to
> hear about it, because currently the resultset has to do a separate
> (sequential or index) scan of the deficiencies table. The only way I can
> see to do
Actually, come to think of it, just the implementation of re-querying a
temporary table could alone significantly improve performance, because the
temp table would:
a) have fewer records to scan on the subselects
b) not require any joins
Thanks!
Terry Fielder
Network Engineer
Great Gulf Homes / A
On Wed, 6 Nov 2002, Achilleus Mantzios wrote:
>
> Hi i think a hit a major problem on 7.2.1.
> I run 3 systems with postgresql 7.2.1.
> Its a redhat 7.1 for development, a redhat 7.3 for production
> and a FreeBSD 4.6.1RC2 for testing.
>
> After long runs (with periodic (daily) vacuum analyze's)
>
On Wed, 6 Nov 2002 [EMAIL PROTECTED] wrote:
> However, for the total deficiencies I am then splitting up the total into
> aging groups, eg <30, 30-60, 60-90, and >90 days old. The query for that
> looks like the below. But before I paste it in, I would like to optimize
> it, if I could do so wit
Now that I've given your problem more thoughts (and searched for similar
stuff),
I think what you need is generating a cross table resp. pivot table.
Related to this, I am thinking of a query using Conditional Expressions
like
COUNT ( CASE WHEN ... THEN 1 ELSE NULL) in order to use GROUP BY.
Toget
On Wednesday 06 Nov 2002 2:01 pm, [EMAIL PROTECTED] wrote:
> However, for the total deficiencies I am then splitting up the total into
> aging groups, eg <30, 30-60, 60-90, and >90 days old. The query for that
> looks like the below. But before I paste it in, I would like to optimize
> it, if I
I was wrong about parent side triggers only having
disappeared.
Triggers of both sides are missing.
==
Achilleus Mantzios
S/W Engineer
IT dept
Dynacom Tankers Mngmt
Nikis 4, Glyfada
Athens 16610
Greece
tel:+30-10-8981112
fax:
No offence taken, however it is incorrect, my SQL is pretty good. I
received no other responses... And I later realized the solution to my
question:
(EXPERTS READ ON: If anyone can show me how to use a group by or otherwise
optimize I would be grateful)
This subquery:
SELECT pr
Also i must that these lost triggers implement the parent table
side of the constraint, e.g.
CREATE TABLE VslSections(
id serial NOT NULL UNIQUE PRIMARY KEY,
name varchar(20) NOT NULL UNIQUE);
CREATE TABLE MachClasses(
id serial NOT NULL UNIQUE PRIMARY KEY,
name varchar(20) NOT NULL UNIQUE,
vslse
Hi i think a hit a major problem on 7.2.1.
I run 3 systems with postgresql 7.2.1.
Its a redhat 7.1 for development, a redhat 7.3 for production
and a FreeBSD 4.6.1RC2 for testing.
After long runs (with periodic (daily) vacuum analyze's)
i noticed that some of the triggers that implement referenti
16 matches
Mail list logo
