Hi., Sorry for my late reply, I wasn't on desk for last few days. My goal is
to set up a spatial database, with postgresql 8.1. I removed the postgresql
installation using apt-get --purge remove. and removed the
var/lib/postgresql/data directory. And then reinstalled it again. The result
I got is h
On Wed, Apr 16, 2008 at 03:41:31PM +0200, Michael Enke wrote:
> >IIRC the casts now use the type's output function. I'm guessing you
> >should be able to do the same with your type.
>
> I thougth there is same functionality with changed name.
> But probably not public available anymore.
> Now I d
[EMAIL PROTECTED] (Alvaro Herrera) writes:
> Geoffrey wrote:
>> Joshua D. Drake wrote:
>>> On Fri, 18 Apr 2008 14:30:18 -0400
>>> Geoffrey <[EMAIL PROTECTED]> wrote:
>>>
I don't know that slony is the answer. It was more of a question
then an answer. We are hoping to use that solution t
On Apr 18, 2008, at 2:04 PM, Joshua D. Drake wrote:
On Fri, 18 Apr 2008 14:59:34 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
I find it pretty unlikely that Slony would be unable to help you
upgrade here. Obviously you can upgrade one database at a time.
Also, mostly it's not the database
Alvaro Herrera wrote:
Geoffrey wrote:
I'm really not altogether sure what you mean by transaction velocity.
I'm pretty sure the electrons are traveling pretty close to the speed of
light. ;)
Actually, electrons themselves flow rather slowly -- millimeters per
second according to Wikipedia.
Geoffrey wrote:
> I'm really not altogether sure what you mean by transaction velocity.
> I'm pretty sure the electrons are traveling pretty close to the speed of
> light. ;)
Actually, electrons themselves flow rather slowly -- millimeters per
second according to Wikipedia. The signal propag
Joshua D. Drake wrote:
> On Fri, 18 Apr 2008 14:59:34 -0400
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> > I find it pretty unlikely that Slony would be unable to help you
> > upgrade here. Obviously you can upgrade one database at a time.
> >
> > Also, mostly it's not the database size what'
Joshua D. Drake wrote:
On Fri, 18 Apr 2008 14:59:34 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
I find it pretty unlikely that Slony would be unable to help you
upgrade here. Obviously you can upgrade one database at a time.
Also, mostly it's not the database size what's a concern, but ra
Alvaro Herrera wrote:
Geoffrey wrote:
Joshua D. Drake wrote:
On Fri, 18 Apr 2008 14:30:18 -0400
Geoffrey <[EMAIL PROTECTED]> wrote:
I don't know that slony is the answer. It was more of a question
then an answer. We are hoping to use that solution to migrate from
7.4.19 to 8.3.1. The prima
On Fri, 18 Apr 2008 14:59:34 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> I find it pretty unlikely that Slony would be unable to help you
> upgrade here. Obviously you can upgrade one database at a time.
>
> Also, mostly it's not the database size what's a concern, but rather
> the size of
First, I am new to Postgres. I am hoping to migrate an existing Java
application from a couple of tried but unreliable open source Java databases. I
have a fair amount of experience with Oracle, Informix and DB2 but it has been
a few years. No on to my problem.
I finally got PostgreSQL installe
Geoffrey wrote:
> Joshua D. Drake wrote:
>> On Fri, 18 Apr 2008 14:30:18 -0400
>> Geoffrey <[EMAIL PROTECTED]> wrote:
>>
>>> I don't know that slony is the answer. It was more of a question
>>> then an answer. We are hoping to use that solution to migrate from
>>> 7.4.19 to 8.3.1. The primary re
On Friday 18 April 2008, Geoffrey <[EMAIL PROTECTED]> wrote:
> What about the:
>
> 8.1 -> slony -> 8.3
> switch users to 8.3 databases
>
> solution.
15+ million row inserts/updates a day across 1000+ tables. Oh, and an
extensive existing Slony structure for some portions of the database.
I could
Joshua D. Drake wrote:
On Fri, 18 Apr 2008 14:30:18 -0400
Geoffrey <[EMAIL PROTECTED]> wrote:
I don't know that slony is the answer. It was more of a question
then an answer. We are hoping to use that solution to migrate from
7.4.19 to 8.3.1. The primary reason is to reduce downtime.
Well
On Fri, 18 Apr 2008 14:30:18 -0400
Geoffrey <[EMAIL PROTECTED]> wrote:
> I don't know that slony is the answer. It was more of a question
> then an answer. We are hoping to use that solution to migrate from
> 7.4.19 to 8.3.1. The primary reason is to reduce downtime.
Well :) That is why I aske
E.J. Moloney escribió:
I am running the following query
update tempportfwdconnectiona set srcid=interface.objectid from
interface where tempportfwdconnectiona.hostid=interface.host and
tempportfwdconnectiona.spantreeport=interface.stpport
For application reasons the spantreeport in one table
Joshua D. Drake wrote:
On Fri, 18 Apr 2008 13:54:52 -0400
Geoffrey <[EMAIL PROTECTED]> wrote:
What about the:
8.1 -> slony -> 8.3
switch users to 8.3 databases
solution.
Is it? What is your transactional velocity? How long will the initial
sync transaction have to run? You know vacuum isn't
E.J. Moloney wrote:
I am running the following query
update tempportfwdconnectiona set srcid=interface.objectid from
interface where tempportfwdconnectiona.hostid=interface.host and
tempportfwdconnectiona.spantreeport=interface.stpport
For application reasons the spantreeport in one table is
I am running the following query
update tempportfwdconnectiona set srcid=interface.objectid from
interface where tempportfwdconnectiona.hostid=interface.host and
tempportfwdconnectiona.spantreeport=interface.stpport
For application reasons the spantreeport in one table is a text field
and an
On Fri, 18 Apr 2008 13:54:52 -0400
Geoffrey <[EMAIL PROTECTED]> wrote:
> What about the:
>
> 8.1 -> slony -> 8.3
> switch users to 8.3 databases
>
> solution.
Is it? What is your transactional velocity? How long will the initial
sync transaction have to run? You know vacuum isn't working while
Alan Hodgson wrote:
On Friday 18 April 2008, Chris Browne <[EMAIL PROTECTED]> wrote:
I note in the blog that the "in place upgrade" issue came up.
(Interesting to observe that it *also* came up pretty prominently in
the intro session at PG East... This is obviously a matter of Not
Inconsiderabl
On Friday 18 April 2008, Chris Browne <[EMAIL PROTECTED]> wrote:
> I note in the blog that the "in place upgrade" issue came up.
> (Interesting to observe that it *also* came up pretty prominently in
> the intro session at PG East... This is obviously a matter of Not
> Inconsiderable Interest...)
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> Keaton Adams írta:
>> How do I tell if the 32 bit version of PostgreSQL is running on a 64
>> bit machine, or if the 64 bit version was installed?
> select version();
> It will tell you the compiler version and arch as well. You can deduce
> from
There is probably a better way of doing this, but if nothing else try
this:
PostgreSQL executables on Unix:
% file postmaster psql
postmaster: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, not stripped
psql:ELF 32-bit MSB executable SPARC Version 1, dynamically
l
[EMAIL PROTECTED] ("Joshua D. Drake") writes:
> On Thu, 17 Apr 2008 22:19:23 -0500
> Josh Trutwin <[EMAIL PROTECTED]> wrote:
>
>> Is your presentation available online at all?
>
> Blogging the bad boy up right now Will be available soon.
The presentation seems pretty good...
... But what is
Keaton Adams írta:
I did search the archives for this But didn’t see a posting that
directly answered the question.
How do I tell if the 32 bit version of PostgreSQL is running on a 64
bit machine, or if the 64 bit version was installed? Is there a pg_
table that I can query or a config f
I did search the archives for this But didn't see a posting that directly
answered the question.
How do I tell if the 32 bit version of PostgreSQL is running on a 64 bit
machine, or if the 64 bit version was installed? Is there a pg_ table that I
can query or a config file I can look in to
Michael Enke <[EMAIL PROTECTED]> writes:
> For my setup, in 8.1 a delete query which deletes 20 entries depending on
> rows in another table
> runs about 7h, in 8.2 (and later) it runs 9s!
If those rowcount estimates are even close to accurate, there's no
reason for the hash plan to be so muc
Dave wrote:
Lets say I have a Postgresql table where I store uploaded data for
all users, identified by user_id column. Is it possible to run a
query to measure the storage a user is consuming?
Not really. You could get the size of the whole table with
pg_relation_size() and then estimate a us
On Wednesday 16 April 2008 13:38, wasenbr wrote:
> Hello,
>
> how can I restore a pg_dumpall dump?
>
> Cleiton
http://www.postgresql.org/docs/8.3/interactive/backup.html
--
Terry Lee Tucker
Turbo's IT Manager
Turbo, division of Ozburn-Hessey Logistics
2251 Jesse Jewell Pkwy NE
Gainesville,
Hi,
your query cant perform well on 8.1
better use a query like
delete from pluext1 using pluext2 where pluext1.plunmbr =
pluext2.plunmbr and pluext1.pluexttype = pluext2.pluexttype
it should perform much faster. be sure to use indizes
regards
thomas
Michael Enke schrieb:
Hi lists,
I want
On Thu, Apr 17, 2008 at 04:06:57AM -0700, Paul Boddie wrote:
> One caveat: psycopg2 doesn't (or didn't) use cursors in a transparent
> fashion like pyPgSQL does. If you're traversing potentially large data
> sets, this will mean that psycopg2 will download all the result data
> into the client pro
Alvaro Herrera wrote:
Michael Enke wrote:
Hi all,
I migrate from 8.1 to 8.3.
In 8.2.7 and previous there are functions int4_text() and int8_text(),
in 8.3.0 they are missing (not documented that they are removed in the release
notes).
What I'm supposed to use instead of int8_text() now?
(I use
Lets say I have a Postgresql table where I store uploaded data for all users,
identified by user_id column. Is it possible to run a query to measure the
storage a user is consuming?
Ideally this would be a SELECT query with WHERE clause on user_id and will only
return size of the data field(s),
Hello,
how can I restore a pg_dumpall dump?
Cleiton
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 15 Apr, 17:53, [EMAIL PROTECTED] (Erik Jones) wrote:
> On Apr 15, 2008, at 10:27 AM, Dawid Kuroczko wrote:
>
> > By the looks of descriptions I am slightly inclined towards
> > psycopg2, but I would feel better if I talked with people
> > who actually used these libraries.
>
> Most definitely ps
Hi lists,
I want to let you take part in my experience of performance boost for delete
operations
where more than one column is part of a primary key.
For my setup, in 8.1 a delete query which deletes 20 entries depending on
rows in another table
runs about 7h, in 8.2 (and later) it runs 9s
Bruce Momjian wrote:
> Ron Mayer wrote:
> > Magnus Hagander wrote:
> > > Craig Ringer wrote:
> > >> with a version of PostgreSQL with the same minor version as the
> > >> one you were using on the server, eg if you were using 8.1.4 you
> > >> should get the latest PostgreSQL in the 8.1 series (NOT
Hello,
> try adding a subnet mask
> host all username 0.0.0.0 0.0.0.0 md5
> or a cidr mask
> host all username 0.0.0.0/0 md5
>
>
that's it. I don't know, why I only wrote 0.0.0.0...
Thats cleary my fault.
Thanks for all your help.
Greetings,
Urkman
39 matches
Mail list logo
