That is indeed true. Also I see you do everything as root, try creating a
new user especially for postgres databases. create a directory with root in
/usr/loca/pgsql/ named data, or any other directory that is in $PGDATA.
chown the directory to the postgres user, log in as the postgres user and
Hugh Esco <[EMAIL PROTECTED]> writes:
>> biko:/usr/bin# ls -al | grep psql
>> lrwxrwxrwx1 root root 10 Oct 10 16:24 psql -> pg_wrapper
> This seems to say that Other users, like postgres, should be able to
> execute it. I'm confused, here.
The permissions attached to a symboli
Here are the results from reversing the arguments.
hesco@biko:~$ su postgres
Password:
postgres@biko:/home/hesco$ cd
postgres@biko:~$ cd /usr/bin
postgres@biko:/usr/bin$ psql tempate1 -U postgres
Could not execv /usr/lib/postgresql/bin/psql
postgres@biko:/usr/bin$ psql template1 -U postgres
Could
Does "Could not execv" mean that I do not have rights to execute this script?
biko:/usr/bin# ls -al | grep psql
lrwxrwxrwx1 root root 10 Oct 10 16:24 psql -> pg_wrapper
biko:/usr/bin#
This seems to say that Other users, like postgres, should be able to
execute it. I'm confuse
>> biko:/usr/bin# psql -U postgres template1
Maybe try : biko:/usr/bin# psql tempate1 -U postgres
I use PG on Debian too. I much prefer to compile from source. It's very
easy why don't you give it a try.
I've never had a problem compiling from source, just make sure to follow
the instruction's
I did this tonight
dpkg --purge postgresql
apt-get install postgresql
and am now still getting the following:
biko:/usr/bin# psql -U postgres
No database specified
biko:/usr/bin# psql -U postgres template1
Could not execv /usr/lib/postgresql/bin/psql
biko:/usr/bin# psql -U postgres template0
Co
Maybe this should be sent to novice... I was not certain, but if it should,
please tell me so.
The matter at hand is this:
When I do an 'INSERT INTO VALUES '
and on the table is a serial primary key named p_key.
As I want this number to be auto-generated, but use it as a 'customer
number', I w
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Tue, 19 Nov 2002, Chris Gamache wrote:
> >> Understood. PostgreSQL 7.2.3.
>
> > 7.3 will be better for this. There were questions about the safety
> > of pushing clauses down in queries with union and inter
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Tue, 19 Nov 2002, Chris Gamache wrote:
>> Understood. PostgreSQL 7.2.3.
> 7.3 will be better for this. There were questions about the safety
> of pushing clauses down in queries with union and intersect and
> earlier versions wouldn't push down becaus
On Tue, 19 Nov 2002, Chris Gamache wrote:
> > If you want help, you must provide details. The PG version number is
> > relevant also.
>
> Understood. PostgreSQL 7.2.3.
7.3 will be better for this. There were questions about the safety
of pushing clauses down in queries with union and intersect
> If you want help, you must provide details. The PG version number is
> relevant also.
Understood. PostgreSQL 7.2.3.
Here's the generated client side sql:
select
case when (hasflag(ut.flags,1) or (current_timestamp - '1 day'::interval <
trl.trans_date)) then
case when trl.trans_data
Chris Gamache <[EMAIL PROTECTED]> writes:
> Right now I dynamicly generate the SQL for an incredibly ugly 4 table join
> based on user information client-side. I got the bright idea to create a view
> and then run a MUUUCH simpler client-side query on that view. The problem is
> that PostgreSQL app
Right now I dynamicly generate the SQL for an incredibly ugly 4 table join
based on user information client-side. I got the bright idea to create a view
and then run a MUUUCH simpler client-side query on that view. The problem is
that PostgreSQL apparantly runs the view FIRST and then applies the c
That's a whole lot faster. The query on 40 msa_codes that took
7 minutes, now only takes 10 seconds.
Thanks a lot.
At 11:54 AM 11/19/2002 -0500, Tom Lane wrote:
Ellen Cyran <[EMAIL PROTECTED]> writes:
> Here is the explain analyze:
> Group (cost=637.18..696.52 rows=593 width=22) (actual
time
Evgen Potemkin wrote:
Joe,
i've made it already,as send first 'Proposal ...' message,
but found a small bug. within nearest days i'll fix it, and post the patch
to pgsql-patches.
Please note that there was no patch attached to your initial proposal
(assuming this is the message you are referr
Did you install your package using apt-get ?
All the instalations that I do are using those tools from debian. You
have to see all the packages that you have instaled in your computer like:
dpkg -l | grep postgresql
ii postgresql 7.2.1-2Object-relational SQL database,
descended fr
i
Ellen Cyran <[EMAIL PROTECTED]> writes:
> Here is the explain analyze:
> Group (cost=637.18..696.52 rows=593 width=22) (actual time=982.67..67581.85
>rows=435 loops=1)
>-> Sort (cost=637.18..637.18 rows=5934 width=22) (actual time=833.27..844.78
>rows=6571 loops=1)
Well, we don't have to
I had to modify your query somewhat, but the one below that is pretty much
the same took
about 12 seconds so once I run it on five years it will take just as
long. Thanks for the
suggestion though.
select distinct on (b.msa_code, b.sic, b.own, b.ind_div)
b.msa_code, b.sic, b.own, b.ind_div, y19
I have reinstalled before. I wonder though, how I ensure that I have
cleanly un-installed it first, so that I leave no residue from the
previously botched installation around to mess things up the next time.
-- Hugh Esco
At 09:03 AM 11/19/02 +, Luis Sousa wrote:
Tom Lane wrote:
Start over:
I have vacuum analyzed recently. I do it after a large number of inserts
and after indexing. This database is in the development stages so there is
a lot of data loading at this time. We are also using 7.2.3. Here is
the explain analyze:
Group (cost=637.18..696.52 rows=593 width=22) (actual
Problem could be the SeqScan on visitor (very last line of explain). This
appears to be coming from the last join in your query. Does an index on ID
exist on Visitor table?
Does changing:
WHERE "VisitorExtra"."ID"="Visitor"."ID" AND
"VisitorExtra"."ID"= 325903;
to
Ellen Cyran <[EMAIL PROTECTED]> writes:
> Is there any way to make this query faster? I have indexes on year,
> msa_code, and sic. I've also tried it with
> an index on the combined group by columns. I've made both sort_mem and
> shared_buffers bigger, but still this query
> takes 40 seconds w
On Mon, 18 Nov 2002, Ellen Cyran wrote:
> Is there any way to make this query faster? I have indexes on year,
> msa_code, and sic. I've also tried it with
> an index on the combined group by columns. I've made both sort_mem and
> shared_buffers bigger, but still this query
> takes 40 seconds wh
Uz.ytkownik sun yu napisa?:
> HI,What can I do to solve this error;
> I have two tables, as below
> tabel: works
>
> empnum | pnum | hours
> +--+---
> E1 | P1 |40
> E1 | P2 |20
> E1 | P3 |80
> E1 | P4 |20
> E1 | P5 |12
> E1
Uz.ytkownik [EMAIL PROTECTED] napisa?:
i don't know how to create the index about the following statement.
SELECT b.screen_id AS screen_id, b.name AS screen_name
FROM tbl_showlog AS a CROSS JOIN
tbl_screen AS b CROSS JOIN
tbl_company AS c
WHERE a.screen_id = b.screen_id
AND b.company_id = c.comp
On Tue, 19 Nov 2002, Evgen Potemkin wrote:
> Oleg,
>
> i've read that info. mine CONNECT BY patch is based on internal pg's query
>processing,
> from that point it's a kind of ORDER BY or GROUP BY clause. Index access is
>implemented by
> lower layer.
ok. I see.
>
> regards,
> ---
> .evgen
>
-Josh,
i don't be so thrilled:), with current implementation of /contrib/tablefunc
mine problem sill remains: i need to sort tree leaves in some order,
independent of tree itself. this can be fixed (in tablefunc) by addition to
connectby() one more field like 'order_by' or so. but it will be more
Joe,
i've made it already,as send first 'Proposal ...' message,
but found a small bug. within nearest days i'll fix it, and post the patch
to pgsql-patches.
i've described why i can't use connectby() in message to Josh Berkus.
i'll enhance CONNECT BY as clause, but not as function. i think it's m
HI,What can I do to solve this error;
I have two tables, as below
tabel: works
empnum | pnum | hours
+--+--- E1 | P1
| 40 E1 | P2
| 20 E1 | P3
| 80 E1 | P4
| 20 E1 | P5
| 12 E1 | P6
| 12 E2 | P1
Oleg,
i've read that info. mine CONNECT BY patch is based on internal pg's query
processing,
from that point it's a kind of ORDER BY or GROUP BY clause. Index access is
implemented by
lower layer.
regards,
---
.evgen
On Sat, 16 Nov 2002, Oleg Bartunov wrote:
> Evgen,
>
> read info about ltr
Is there any way to make this query faster? I have indexes on year,
msa_code, and sic. I've also tried it with
an index on the combined group by columns. I've made both sort_mem and
shared_buffers bigger, but still this query
takes 40 seconds when I select 4 msa_codes and 7 minutes when I sele
i don't know how to create the index about the following statement.
SELECT b.screen_id AS screen_id, b.name AS screen_name
FROM tbl_showlog AS a CROSS JOIN
tbl_screen AS b CROSS JOIN
tbl_company AS c
WHERE a.screen_id = b.screen_id
AND b.company_id = c.company_id
AND c.company_id = 1
AND c.is_act
On Tuesday 19 Nov 2002 9:10 am, Tomas Berndtsson wrote:
> Hi,
>
> I have a question about index usage in PostgreSQL 7.2.1 on Solaris.
>
> At first, I did the query like this:
>
> SELECT po.portno,po.element,s.sname,pri,p.pname,value
> FROM port po, port_s s LEFT OUTER JOIN port_s_p p
> USING (elem
Hi,
I have a question about index usage in PostgreSQL 7.2.1 on Solaris.
I have three tables like this:
port: element text
portnoint
primary key: element, portno
index: element
port_s: element text
portnoint
sname text
pri int
primary key: elem
Tom Lane wrote:
Hugh Esco <[EMAIL PROTECTED]> writes:
Any ideas on what my next steps should be would be greatly appreciated.
Start over: delete your PG installation and reinstall the Debian
package. It seems very clear that you've got an incomplete package.
regards, tom lane
I a
Uz.ytkownik Hugh Esco napisa?:
Thank you so much, Mallah, Tomasz Myrta, Luis Sousa,
Achilleus Mantzios, Tom Lane, Bill Eaton and Oliver Elphick.
I have chmod 755 my readpgenv file, and then copied the
shell script suggested by Tomasz Myrta into that file,
yielding these results:
biko:/usr/li
36 matches
Mail list logo
