Hello.
I'm running `PostgreSQL 7.2 on i586-pc-linux-gnu, compiled by GCC 2.95.3'
and have some problems with queries on a view.
I've got two tables: working one and archive and one view, I've attached the
description.
And here is my problem: queries on a view runs to much time.
explain analyze
hi all,
I have a strange problem and really wish to get some help in here.
I have the following tables
create table shr_objects(
objectidint8not null
companyid int4not null
namevarchar(255)
description varchar(255)
)
primary
On Mon, 10 Mar 2003 10:12:15 +0100
Tomasz Myrta <[EMAIL PROTECTED]> wrote:
> Andre Schubert wrote:
> > Hi all,
> >
> > i have a little problem on indexing a table which contains
> > about 4 millions of traffic-data.
> > My problem is, that a want to select all data from
> > a specific month from
Josh Berkus <[EMAIL PROTECTED]> writes:
>> db=#explain vacuum;
>> to return:
>> NOTICE: "vacuum" is an internal postgresql feature.
>> instead of:
>> ERROR: parser: parse error at or near "vacuum" at character 9
> No, it would not.
Actually, it's a fair question considering that the 7.3 man pag
Hello Christoph Haller ,
> >
> > >So you want the trigger executed only if assignments to b and/or c do
Do sime thing like this use if /then /esle s block for the problem
In the first if blick check that b and c is null by the declaration of
IS NULL after that you run the update command as re
Objectz wrote:
> Oops .. Here they are
>
>
> =
>
> intranet=# explain analyze SELECT obj.companyid, obj.name,
> obj.description, intranet-# cnt.firstname, cnt.lastname intranet-# FROM
> smb_contacts cnt JOIN shr_objects ob
>
> >So you want the trigger executed only if assignments to b and/or c do
> >not appear within the update command. Right?
> >
>
> Right, that's what I want.
>
I'm afraid I have no idea how to accomplish that.
Regards, Christoph
---(end of broadcast)
Andre Schubert <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> Update to 7.3, and that problem will go away.
>>
> What is the difference between 7.2 and 7.3 related to my problem ?
7.3 is willing to index comparisons to now(), that's what ;-)
You may care to study the differ
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> but just give a warning and then run the underlying
>> query _again_, this toime with materialize on top and also do a Move to
>> reposition the cursor. This will probably not work correctly for all
>> tranasaction isolation levels though b
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
>> There are cases where
>> identical cursor definitions might allow or not allow backwards fetch
>> depending on the planner's choices.
> Would it be possible to give warnings in a narrow superset of the
> problematic cases, something along the li
Just a reminder that we could use cursors that exist after transaction
commit (WITH HOLD) and updatable cursors (WHERE CURRENT OF cursorname). :-)
---
Tom Lane wrote:
> "Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> >>
Tom Lane kirjutas P, 09.03.2003 kell 22:35:
> However, this is going to create backwards-compatibility issues.
> We have a few options for what to do:
>
> 1. Enforce the SQL spec requirement: error out if backwards fetch is
> done when SCROLL wasn't given. But this will surely break a lot
> of e
12 matches
Mail list logo
