On Fri, Feb 24, 2006 at 11:57:57AM +0530, sandhya wrote:
> In select lo_unlink(objid) from (select distinct objid from filetbl)AS s;
> the above query what is that 'S' stands for in AS 'S'
"s" is a table alias, which is required for a subquery. The choice
of "s" is arbitrary; it can be any valid
Thank You Fuhr.
In select lo_unlink(objid) from (select distinct objid from filetbl)AS s;
the above query what is that 'S' stands for in AS 'S'
Can u pls explain me.
- Original Message -
From: "Michael Fuhr" <[EMAIL PROTECTED]>
To: "sandhya" <[EMAIL PROTECTED]>
Cc: "Postgres"
Sent:
On Thu, Feb 23, 2006 at 11:49:46PM +, Robin Iddon wrote:
> Jim C. Nasby wrote:
>
> >Please upgrade.
> >
> >Are you running with the default FSM settings? I'm guessing that
> >pg_statistics has just gotten so large that it's blowing out the FSM.
> >The last few lines from vacuumdb -av would ver
Jim C. Nasby wrote:
Please upgrade.
Are you running with the default FSM settings? I'm guessing that
pg_statistics has just gotten so large that it's blowing out the FSM.
The last few lines from vacuumdb -av would verify that...
Jim,
I am running this in a critical production environment,
On Thu, Feb 23, 2006 at 11:44:47PM +, Robin Iddon wrote:
>
> >
> >In fact I just noticed that the number of stats tuples just climbed
> >from 1236 to 2634. The ins/del counts are still zero. I ran analyze
> >and the update counter went up only by 1232. For pg_autovacuum to
> >vacuum this
In fact I just noticed that the number of stats tuples just climbed
from 1236 to 2634. The ins/del counts are still zero. I ran analyze
and the update counter went up only by 1232. For pg_autovacuum to
vacuum this table I need (2*2634)+1000 = 6268 updates, which is never
going to happen.
On Thu, Feb 23, 2006 at 11:34:22PM +, Robin Iddon wrote:
> From that I see that the pg_statistics table is never inserted/deleted
> only updated (ins/del counts are 0), and in principle simply analyzing
> doesn't increase the tuple count.
Sure it does. An update in PostgreSQL is essentially
Tom,
Tom Lane wrote:
Quite incorrect --- if that were so, there would be no dead tuples
for vacuum to remove, hm? Actually ANALYZE does an
update-or-insert-if-not-present fandango.
Thanks for the correction - I was basing my comments on the fact that
the tuple count was just climbing for
Moritz,
The only problem you'll have with regard to configuration issues, is
your local applications might try connecting using the 7.4 client
libraries as opposed to the 8.1, however if you didn't add a --prefix
option to your configure, it should overwrite the old libraries with the
new ref
Look at your pg_hba.conf file - your old configuration might have had a
"trust" authentication set somewhere for your local machine/network IPs,
rendering any password unnecessary.
Andy
Mr. Dan wrote:
Hi,
When I was running 8.0.X on linux, I didn't have to include the
postgres -P password i
On Thu, Feb 23, 2006 at 02:54:48PM -0700, Michael Fuhr wrote:
> I'd guess you're trying to dump an empty table.
Or maybe you're issuing a query that returns no rows.
% psql -d postgis -c 'select max(gid) from feb3'
max
-
2
(1 row)
% pgsql2shp postgis 'select * from feb3 where gid > 2'
P
On Thu, Feb 23, 2006 at 01:48:54PM -0600, Sunanda Kumaraguru wrote:
> Iam trying to use the postgis dumper.I get the follwing error.
>
> ERROR: Cannot determine geometry type (empty table).
What exactly did you do to get this error? Are you trying to use
pgsql2shp? After loading your data it wo
On Thu, Feb 23, 2006 at 01:48:54PM -0600, Sunanda Kumaraguru wrote:
> Hello Everyone,
>
> Iam trying to use the postgis dumper.I get the follwing error.
>
> ERROR: Cannot determine geometry type (empty table).
>
>
>
> Iam sending the sql file as an attachment.
>
> Any suggestions from your s
"Mr. Dan" <[EMAIL PROTECTED]> writes:
> Has anyone else noticed they had to start including a password for
> the postgres user in 8.1.X?
No. I'll bet a very good dinner that you changed the pg_hba.conf
configuration file when you updated the PG installation.
regards, tom
On Thu, Feb 23, 2006 at 01:54:06PM -0500, Yantao Shi wrote:
> We have PostGIS 1.1.1 installed and I am trying to get it to work with
> Postgres8.1.1 on our system.
>
> Could some one give me a small sample script that lets me connect to
> postgis from Postgres?
PostGIS is a third-party extensi
Robin Iddon <[EMAIL PROTECTED]> writes:
> The tuples and thresholds for the pg_statistic table look like they
> might be the reason it doesn't get vacuumed. The question is, why does
> the reltuples on the stats table keep climbing until you do a vacuum
> full, at which point they return to (ne
Depending on your actual config, you could well be able to set
postgresql up so that it doesn't need any passwords, too. I prefer this
when possible... but you need to understand the rammifications if you
care about your data.
Though, if all you're doing is running pgbench, I'd say just setup
ever
On Thu, Feb 23, 2006 at 01:54:06PM -0500, Yantao Shi wrote:
> We have PostGIS 1.1.1 installed and I am trying to get it to work with
> Postgres8.1.1 on our system.
>
> Could some one give me a small sample script that lets me connect to
> postgis from Postgres?
>
> I have never used postgis be
Please upgrade.
Are you running with the default FSM settings? I'm guessing that
pg_statistics has just gotten so large that it's blowing out the FSM.
The last few lines from vacuumdb -av would verify that...
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software
Thanks Milen!
I use -P is bash shell scirpts. It used with with pgbench.
see pgbench --help.
~DjK
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED
Mr. Dan написа:
> Hi,
>
> When I was running 8.0.X on linux, I didn't have to include the postgres
> -P password in my shell scripts(.sh). After I switched to 8.1.X, I've
> had to include the -P PASSWORD ** in all my scripts. I'm thinking
> I'll just add PGPASSWORD as a postgres environment
Make sure that you initdb the postgresql cluster as the user "postgres"
not as "root".
So, after configuring, compiling, and installing the source, switch user
to "postgres" and run your initdb command.
Husam
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTE
Hello Everyone,
Iam trying to use the postgis dumper.I get the follwing error.
ERROR: Cannot determine geometry type (empty table).
Iam sending the sql file as an attachment.
Any suggestions from your side would be of great help to me.
Thanks
sunanda
Hi,
When I was running 8.0.X on linux, I didn't have to include the postgres -P
password in my shell scripts(.sh). After I switched to 8.1.X, I've had to
include the -P PASSWORD ** in all my scripts. I'm thinking I'll just
add PGPASSWORD as a postgres environment variable instead. I di
Third: Are you seeing in the autovacuum log that autovacuum is
actually trying to vacuum tables? Turn up the debugging to -d2 that
should give you some more info as to why autovac is (or is not) doing
what it's doing.
I will turn it on and take a look. I am guessing it will tell me that
We have PostGIS 1.1.1 installed and I am trying to get it to work with
Postgres8.1.1 on our system.
Could some one give me a small sample script that lets me connect to
postgis from Postgres?
I have never used postgis before. I need to test its geo-spatial
functionality with Postgres.
Tha
Hi Matt,
Thanks for the reply.
Matthew T. O'Connor wrote:
What do you mean by stats table entries? Are you saying there is
bloat in a specific table, or just the whole database?
The table in question is pg_statistic. It's pages as reported by
pg_class.relpages grow without bound until I
On Thu, 2006-02-23 at 16:18 +, Andy Shellam wrote:
> Cheers for the idea Simon, now to get coding...!
S'OK ... it was designed that way from the start.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 3: Have you checked our extensive
Yes, if you are concerned about the performance of updates/deletes on
the departments table. The reason the system doesn't make such an index
automatically is that there are common scenarios where you seldom or
never update the master table, and so the index wouldn't repay the cost
it creates for
Arnau <[EMAIL PROTECTED]> writes:
>> The referencED column is forced to have an index. The referencING
>> column is not. The cases where you need an index on the latter are
>> precisely updates/deletes of the referencED column.
>Lets put an example
>CREATE TABLE departments
>(
>
Hi Moritz - you got
8.1.3 going then? Excellent :-D
You need to try a number of things to find the exact package for 7.4 to
remove.
Firstly, see if either apt-get or yum is installed on your system.
Then you can do
apt-get remove pgsql
apt-get remove postgres
apt-get remove postgresql
(or
Hello again,
I've installed Postgres Version 8.1.3 on my Linux machine from sourcecode. Before that, there was already the version 7.4 running.
May be a dumn question, but how do I deinstall the Version 7.4?
Thanks for your help,
Moritz
Hi Simon,
Many thanks for this suggestion - this sounds ideal actually. My
thoughts on this are, I would write a shell script that gets called for
each file requested in the recovery.conf ...
a) If the log file requested exists, copy it and exit with 0 status
b) If the file doesn't exist, ch
On Thu, Feb 23, 2006 at 01:24:43PM +0530, sandhya wrote:
> Is there any possibility to delete /Unlink a group of large objects at a
> time?
> Please tell me .To test my application i have loaded somany files into
> database.
> Now i want to unlink all those objects.
You could call lo_unlink() i
On Wed, 2006-02-22 at 16:26 +, Andy Shellam wrote:
> Is this scenario possible - that you can keep rolling forward over log
> files as long as necessary, or do you always have to start from a base
> backup? Nothing is changing on the spare, it's literally a sitting
> duck.
You'll need a rest
Hi all,
Maybe the direction this thread has taken is a bit out of the scope
of this mailing list, but I think it's very interesting and can be
useful for newbie users.
The usual cause of slow deletes is that (a) the table is the target of
some foreign key references from other large tabl
Hi,
I wonder if anyone can help me to identify why my background
pg_autovacuum doesn't appear to clear out the stats table entries?
Here is the non-commented lines in my postgresql.conf:
max_connections = 100
shared_buffers = 1000 # min 16, at least max_connections*2,
8KB each
vac
hi...
Is there any possibility to delete /Unlink a group of
large objects at a time?
Please tell me .To test my application i have loaded somany
files into database.Now i want to unlink all those objects.
Please help me in doing this...
Thanks,
Sandhya
38 matches
Mail list logo
