On Mon, 22 Oct 2001, Reiner Dassing wrote:
> Hello PostgreSQl Users!
>
> PostSQL V 7.1.1:
>
> I have defined a table and the necessary indices.
> But the index is not used in every SELECT. (Therefore, the selects are
> *very* slow, due to seq scan on
> 20 million entries, which is a test setup
Reinier,
For future notice, [SQL] is the correct list for this kind of inquiry.
Please do not post it to [HACKERS]. And please don't cross-post ... it
results in a lot of needless duplication of effort.
> I have defined a table and the necessary indices.
> Is the order of index creation releva
On Mon, 22 Oct 2001, Esteban Gutierrez Abarzua wrote:
>
> hi.
>
> I wanna to make a query on this table(postgres system catalog):
>
> Attribute | Type| Modifier
> --+---+--
> relname | name |
> reltype | oid |
> relowner | in
Hello PostgreSQl Users!
PostSQL V 7.1.1:
I have defined a table and the necessary indices.
But the index is not used in every SELECT. (Therefore, the selects are
*very* slow, due to seq scan on
20 million entries, which is a test setup up to now)
The definitions can be seen in the annex.
Does
hi.
I still have the data type problem.
I am working with the postgresql system catalog
On Sat, 20 Oct 2001, Joel Burton wrote:
> On Sat, 20 Oct 2001, Aasmund Midttun Godal wrote:
>
> > Can a rule see the where statement in a query which it has been
> > triggered by? or is it simply ignored?? what happens?
> >
>
> Looking over your question, I wanted to clarify the problem a bit,
hi.
I wanna to make a query on this table(postgres system catalog):
Attribute | Type| Modifier
--+---+--
relname | name |
reltype | oid |
relowner | integer |
relam| oid |
relpages | integer |
reltup
Aasmund,
Thank you for the clarification. Now that I know what you are doing, I
went through exactly the same thing about a year ago ... which is how we
discovered some additional problems with using OIDs in database design.
I was trying to spare you the same dead end.
> > If your probl
On Mon, 22 Oct 2001, Josh Berkus wrote:
> Each significant data table contains one column, the first column,
> called "usq", for "universal sequence". This usq field may or may not
> be the primary key for the table, but does have a unique index. The usq
> is populated by a single sequence "uni
> Don't think so. I think the rule doesn't make any sense.
> NEW.id and OLD.id are probably dbl values, so saying OLD.id=id (where id
> is raw.id since that's the update table) isn't correct. It probably
> should be OLD.id=id*2 (which seems to work for me, btw) It's editing
> a different row t
Joel Burton <[EMAIL PROTECTED]> writes:
> CREATE VIEW dbl AS SELECT id * 2 as id, name FROM raw;
> CREATE RULE dbl_update AS ON UPDATE TO dbl DO INSTEAD UPDATE raw SET
> id = NEW.id, name = NEW.name WHERE OLD.id = id;
Surely you'd need something like
CREATE RULE dbl_update AS ON UPDATE TO dbl D
That is what i did...
Regards,
Aasmund
On Sat, 20 Oct 2001 23:34:44 -0400 (EDT), Joel Burton <[EMAIL PROTECTED]> wrote:
> On Sun, 21 Oct 2001, Aasmund Midttun Godal wrote:
>
>
>
> Aasmund --
>
> If your problem is that you want to update VIEWs and aren't sure what the
> PK for the view is,
Yes, I agree perfectly... I never thought of that! I would really like it if some more
info was added to the docs regarding info on rules and triggers. The section on update
rules is quite good, but some more would never hurt. One point in the trigger vs rules
section which at least to me is ve
Yes, I agree perfectly... I never thought of that! I would really like it if some more
info was added to the docs regarding info on rules and triggers. The section on update
rules is quite good, but some more would never hurt. One point in the trigger vs rules
section which at least to me is ve
On Wed, 17 Oct 2001 17:17:44 METDST
Haller Christoph wrote:
> I use the second table to identify the actual resp. obsolete ones within the first
>table.
>
> DELETE FROM advncd_tempreftime;
> INSERT INTO advncd_tempreftime
> SELECT timepoint,mid,lid,sid,MAX(entrancetime) FROM advncd_onfvalue
15 matches
Mail list logo
