[SQL] DBCC CheckIdent in a stored proc?

2003-01-22 Thread smoghe
Hello All,   I need to know the last id of the last record added to the table from an ASP page.   How do I package DBCC CheckIdent(@tableName) in a output  parameter?   Thanx! Shrirang   p.s: I am a total newbie to DB.

Re: [SQL] To use a VIEW or not to use a View.....

2003-01-22 Thread Tom Lane
Stephan Szabo <[EMAIL PROTECTED]> writes: > On Wed, 22 Jan 2003, Tom Lane wrote: >> Stephan Szabo <[EMAIL PROTECTED]> writes: >>> The filter is applied only to a. So, if you really wanted the >>> c.a=3 condition to be applied for whatever reason you're out of >>> luck. >> >> FWIW, CVS tip is brig

Re: [SQL] To use a VIEW or not to use a View.....

2003-01-22 Thread Stephan Szabo
On Wed, 22 Jan 2003, Tomasz Myrta wrote: > Stephan Szabo wrote: > > >That's not the same join for optimization purposes > >since postgresql treats explicit join syntax as a > >constraint on the ordering of joins. > > > >The same join would be something like: > > > >przystanki p1 join miasta m1 usi

Re: [SQL] To use a VIEW or not to use a View.....

2003-01-22 Thread Stephan Szabo
On Wed, 22 Jan 2003, Tom Lane wrote: > Stephan Szabo <[EMAIL PROTECTED]> writes: > > The filter is applied only to a. So, if you really wanted the > > c.a=3 condition to be applied for whatever reason you're out of > > luck. > > FWIW, CVS tip is brighter: the condition does propagate to both re

Re: [SQL] To use a VIEW or not to use a View.....

2003-01-22 Thread Tomasz Myrta
Stephan Szabo wrote: That's not the same join for optimization purposes since postgresql treats explicit join syntax as a constraint on the ordering of joins. The same join would be something like: przystanki p1 join miasta m1 using (id_miasta) join (przystanki p2 join miasta m2 using (id_miast

Re: [SQL] To use a VIEW or not to use a View.....

2003-01-22 Thread Tom Lane
Stephan Szabo <[EMAIL PROTECTED]> writes: > ... but this is a general transitivity constraint AFAIK, not > one actually to do with views (ie, if you wrote out the query without a > view, you can run into the same issue). It's somewhat easier to run into > the case with views and the effect may be

Re: [SQL] To use a VIEW or not to use a View.....

2003-01-22 Thread Stephan Szabo
On Wed, 22 Jan 2003, Tomasz Myrta wrote: > Let's make some test: > > First, let's create some simple view with 2 tables join: > drop view pm; > create view pm as > select >id_przystanku, >m.nazwa > from >przystanki p >join miasta m using (id_miasta); > > explain select * from pm

Re: [SQL] Speed depending of Join Order.

2003-01-22 Thread Tom Lane
=?iso-8859-1?Q?Ra=FAl=20Guti=E9rrez=20S=E1nchez?= <[EMAIL PROTECTED]> writes: > Note that the only difference is the order of the join elements. Using > version 7.2.2, which I have been using untill now, the time expended in > both of them was the same, using the right indexes. However, using > ver

Re: [SQL] To use a VIEW or not to use a View.....

2003-01-22 Thread Tomasz Myrta
Stephan Szabo wrote: On Wed, 22 Jan 2003, Tomasz Myrta wrote: Tomasz Myrta writes: I'd like to split queries into views, but I can't join them - planner search all of records instead of using index. It works very slow. I think this is the same issue that Stephan identified in his response

Re: [SQL] To use a VIEW or not to use a View.....

2003-01-22 Thread Tomasz Myrta
Stephan Szabo wrote: On Wed, 22 Jan 2003, Tomasz Myrta wrote: Tomasz Myrta writes: I'd like to split queries into views, but I can't join them - planner search all of records instead of using index. It works very slow. I think this is the same issue that Stephan identified in his response

Re: [SQL] To use a VIEW or not to use a View.....

2003-01-22 Thread Jan Wieck
Tomasz Myrta wrote: > > Jan Wieck wrote: > > >Use tables, views and views over views, it's all fine and your indexes > >will be used. > > I can't agree with using views over views. It has some limitations. > I asked about it on this list several months ago > and Tom Lane's conclusion was: It ha

Re: [SQL] To use a VIEW or not to use a View.....

2003-01-22 Thread Stephan Szabo
On Wed, 22 Jan 2003, Tomasz Myrta wrote: > >> Tomasz Myrta <[EMAIL PROTECTED]> writes: > >> I'd like to split queries into views, but I can't join them - planner > >> search all of records instead of using index. It works very slow. > > > I think this is the same issue that Stephan identified in h

Re: [SQL] To use a VIEW or not to use a View.....

2003-01-22 Thread Tomasz Myrta
Jan Wieck wrote: Use tables, views and views over views, it's all fine and your indexes will be used. I can't agree with using views over views. It has some limitations. I asked about it on this list several months ago and Tom Lane's conclusion was: Tomasz Myrta <[EMAIL PROTECTED]> writes: I

Re: [SQL] To use a VIEW or not to use a View.....

2003-01-22 Thread Stephan Szabo
On Wed, 22 Jan 2003, Ries van Twisk wrote: > Dear PostgreSQL users, > > I have a view and a table, > > I understand that when a frontend accesses a VIEW that PostgreSQL cannot use > a index on that view. > For example when I do this: SELECT * FROM full_cablelist WHERE > projectocode=5; Correct?

Re: [SQL] To use a VIEW or not to use a View.....

2003-01-22 Thread Tomasz Myrta
Ries van Twisk wrote: Dear PostgreSQL users, I have a view and a table, I understand that when a frontend accesses a VIEW that PostgreSQL cannot use a index on that view. For example when I do this: SELECT * FROM full_cablelist WHERE projectocode=5; Correct? Now I just want to make sure for my

Re: [SQL] To use a VIEW or not to use a View.....

2003-01-22 Thread Jan Wieck
Ries van Twisk wrote: > > Dear PostgreSQL users, > > I have a view and a table, > > I understand that when a frontend accesses a VIEW that PostgreSQL cannot use > a index on that view. > For example when I do this: SELECT * FROM full_cablelist WHERE > projectocode=5; Correct? No. > > Now I j

Re: [SQL] To use a VIEW or not to use a View.....

2003-01-22 Thread Bruno Wolff III
On Wed, Jan 22, 2003 at 16:12:52 +0100, Ries van Twisk <[EMAIL PROTECTED]> wrote: > Dear PostgreSQL users, > > I understand that when a frontend accesses a VIEW that PostgreSQL cannot use > a index on that view. > For example when I do this: SELECT * FROM full_cablelist WHERE > projectocode=5; C

[SQL] To use a VIEW or not to use a View.....

2003-01-22 Thread Ries van Twisk
Dear PostgreSQL users, I have a view and a table, I understand that when a frontend accesses a VIEW that PostgreSQL cannot use a index on that view. For example when I do this: SELECT * FROM full_cablelist WHERE projectocode=5; Correct? Now I just want to make sure for myself if the VIEW I creat

[SQL] PostgreSQL + SSL

2003-01-22 Thread Pedro Igor Craveiro e Silva
I´m trying to config PG with SSL, but i got a error. I create the key and the certificate and put both in $PGDATA directory. I also enabled the ssl option in postgresql.conf. But when i run postmaster i got a error saying that server.key has wrong permissions.   Thanks,   Pedro Igor

Re: [SQL] optimal sql

2003-01-22 Thread Achilleus Mantzios
On Wed, 22 Jan 2003, Michael Paesold wrote: > Achilleus Mantzios <[EMAIL PROTECTED]> wrote: > > > For a) do all the necessary tuning on PostgreSQL. > > With 1GB of Mem, you could set a value of shared_buffers to 10. > > Perhaps just a type, but that is way to much! It would mean about 800 Mb >

Re: [SQL] optimal sql

2003-01-22 Thread Tomasz Myrta
Michael Hostbaek wrote: Hi, I am running postgresql 7.2.3 on a test server (with potential of becoming my production server). On the server I have a perl script, that is grabbing some data from a inventory database (local) - with some subselects. The query is like this: my $sth = $ppdb->prepa

Re: [SQL] optimal sql

2003-01-22 Thread Tomasz Myrta
Michael Hostbaek wrote: Tomasz Myrta (jasiek) writes: 3. Explain analyze would be helpful like in most performance cases... The same with SQL query instead of Perl script. Explain analyze: NOTICE: QUERY PLAN: Limit (cost=27.55..27.55 rows=1 width=183) (actual time=35364.89..35365.04 row

Re: [SQL] optimal sql

2003-01-22 Thread Michael Hostbaek
Tomasz Myrta (jasiek) writes: > > 3. Explain analyze would be helpful like in most performance cases... > The same with SQL query instead of Perl script. Explain analyze: NOTICE: QUERY PLAN: Limit (cost=27.55..27.55 rows=1 width=183) (actual time=35364.89..35365.04 rows=10 loops=1) -> Sor

Re: [SQL] optimal sql

2003-01-22 Thread Michael Paesold
Achilleus Mantzios <[EMAIL PROTECTED]> wrote: > For a) do all the necessary tuning on PostgreSQL. > With 1GB of Mem, you could set a value of shared_buffers to 10. Perhaps just a type, but that is way to much! It would mean about 800 Mb shared buffers! I would rather suggest a value between 1

Re: [SQL] NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index

2003-01-22 Thread Ludwig Lim
--- David Durst <[EMAIL PROTECTED]> wrote: > Can anyone tell me why postgres is creating a > implicit index when > I already have a PKEY specified > > Or am I just interpreting this all wrong? PostgreSQL uses UNIQUE INDEX to enforce PRIMARY KEY constraint. Therefore creating a PRIMARY KEY

Re: [SQL] optimal sql

2003-01-22 Thread Achilleus Mantzios
On Wed, 22 Jan 2003, Michael Hostbaek wrote: > Hi, I would suggest looking at the problem in three directions: a) PostgreSQL system wise b) PostgreSQL sql wise c) FreeBSD wise. For a) do all the necessary tuning on PostgreSQL. With 1GB of Mem, you could set a value of shared_buffers to 10.

[SQL] NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index

2003-01-22 Thread David Durst
Can anyone tell me why postgres is creating a implicit index when I already have a PKEY specified Or am I just interpreting this all wrong? Here is the entry I am putting in: create sequence journal_line_id_seq increment 1 start 1; create table journal_lines ( journal_line_id int4 PRIMARY

[SQL] optimal sql

2003-01-22 Thread Michael Hostbaek
Hi, I am running postgresql 7.2.3 on a test server (with potential of becoming my production server). On the server I have a perl script, that is grabbing some data from a inventory database (local) - with some subselects. The query is like this: my $sth = $ppdb->prepare(" select partno, cr