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
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
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.
--- 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
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
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
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
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
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
>
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
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
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
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
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
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?
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
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
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
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
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
=?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
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
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
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
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
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
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
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.
28 matches
Mail list logo
