Hi,
We want to reindex the database behind a production service without
interrupting the service.
I had an idea for creating the index with a new name then dropping the existing
index and renaming the new one - and it seems to work and would reduce the time
without an index to be minimal. I t
2010/5/31 Nilesh Govindarajan :
> I run my site (see my signature) on a self managed VPS. I was using
> the default PGSQL RPM from the fedora repository, the site was getting
> way slow. So I compiled all the stuff apache, php and postgresql with
> custom gcc flags, which improved performance like
On 01/06/10 11:05, Tom Lane wrote:
> Bruce Momjian writes:
>> Tom Lane wrote:
>>> Personally I would reduce this section to
>>> Don't.
>
>> Well, I would have avoided this mine-trap except we have this 9.0
>> release note item:
>>Allow use of C++ functions in backend code (Kurt
>>
2010/6/1 Devrim GÜNDÜZ :
> Hi,
>
> On Tue, 2010-06-01 at 06:59 +0530, Nilesh Govindarajan wrote:
>> Self compilation has the advantage of custom gcc flags like -O3 -march
>> -msse, etc. which can improve performance.
>
> I started to think that you have zero idea about building binary
> packages.
>
On Tue, 2010-06-01 at 07:20 +0200, Adrian von Bidder wrote:
> Packaging stuff for Debian is not magic, it's just Makefiles,
> Perl/shell scripts and stuff like this.
Given that *even I* ( :P ) could build a few 8.2 .deb packages for my
previous employer, I also want to confirm that building .deb
Hi,
On Tue, 2010-06-01 at 06:59 +0530, Nilesh Govindarajan wrote:
> Self compilation has the advantage of custom gcc flags like -O3 -march
> -msse, etc. which can improve performance.
I started to think that you have zero idea about building binary
packages.
> Building RPMs is not a task that ev
Heyho!
On Tuesday 01 June 2010 06.01:02 Greg Smith wrote:
> Put a little time into learning how to build
> your own packages instead, to work around this one perceived flaw, and
> you'll be way ahead of the mess that comes with switching distributions
> altogether.
Note that we can always use
On Tuesday 01 June 2010 03.08:06 Clemens Schwaighofer wrote:
> Besides the fact that new versions come in quite fast (after the wait
> phase from unstable to testing)
... and you can always mix testing and unstable. If your testing
installation is not too old, usually not much fiddling with depe
On 01/06/10 10:48, Tom Lane wrote:
Too bad two out of the four pieces of advice are wrong (how many pieces
of memory managed by the backend are allocated directly with malloc?).
The other two are not wrong as far as they go, but they're certainly
woefully inadequate, because no interesting backe
Michal Szymanski wrote:
Currently we use Debian, but it chosen by our OS admnistrator. Now we
can change our OS and it is question what Linux edition will be the
best. We would like have access to new versions of Postgres as soon
as possible, for Debian sometimes we had to wait many weeks for
of
Joachim Worringen wrote:
my Python application (http://perfbase.tigris.org) repeatedly needs to
insert lots of data into an exsting, non-empty, potentially large
table. Currently, the bottleneck is with the Python application, so I
intend to multi-thread it. Each thread should work on a part of
Tom Lane wrote:
> Bruce Momjian writes:
> >>> Well, I would have avoided this mine-trap except we have this 9.0
> >>> release note item:
> >>> Allow use of C++ functions in backend code (Kurt
> >>> Harriman, Peter Eisentraut)
>
> > So should I just comment it out and then when someone gets se
Bruce Momjian writes:
>>> Well, I would have avoided this mine-trap except we have this 9.0
>>> release note item:
>>> Allow use of C++ functions in backend code (Kurt
>>> Harriman, Peter Eisentraut)
> So should I just comment it out and then when someone gets serious we
> can use it as a
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Personally I would reduce this section to
> >>Don't.
>
> > Well, I would have avoided this mine-trap except we have this 9.0
> > release note item:
> >Allow use of C++ functions in backend code (Kurt
> >Harriman,
Bruce Momjian writes:
> Tom Lane wrote:
>> Personally I would reduce this section to
>> Don't.
> Well, I would have avoided this mine-trap except we have this 9.0
> release note item:
>Allow use of C++ functions in backend code (Kurt
>Harriman, Peter Eisentraut)
I'd be inter
Tom Lane wrote:
> Bruce Momjian writes:
> > That is great new information. I have created a new documentation
> > section called "Using C++ for Extensibility", and listed you as the
> > author in the CVS commit; patch attached. Thanks.
>
> Too bad two out of the four pieces of advice are wron
Bruce Momjian writes:
> That is great new information. I have created a new documentation
> section called "Using C++ for Extensibility", and listed you as the
> author in the CVS commit; patch attached. Thanks.
Too bad two out of the four pieces of advice are wrong (how many pieces
of memory
On Tue, Jun 1, 2010 at 11:30, Nilesh Govindarajan wrote:
> Nope; you're wrong. Even RPM doesn't remove the data. But its always
> safer to keep a backup.
I am not talking about removing the data I am talking of not beeing
able to access it because the database itself is still in the old
version.
Craig Ringer wrote:
> Igor wrote:
> > Hi All,
> >
> > Is there an easy way to add c++ files to my simple pgsql module ? My
> > Makefile
> > is as follows -
> >
> > ===
> > MODULES = pg_uservars
> > DATA_built = pg_uservars.sql
> > PGXS := $(shell pg_config --pgxs)
> > include $(PGXS)
> > ===
>
On Tue, Jun 1, 2010 at 6:38 AM, Clemens Schwaighofer
wrote:
> Hi,
>
> I run debian/testing since years and it is the best in my opinion.
> Besides the fact that new versions come in quite fast (after the wait
> phase from unstable to testing) the upgrade for major versions (eg 8.3
> to 8.4) is ver
Hi,
I run debian/testing since years and it is the best in my opinion.
Besides the fact that new versions come in quite fast (after the wait
phase from unstable to testing) the upgrade for major versions (eg 8.3
to 8.4) is very simple as it does not override the old files but does
a parallel insta
On Tue, Jun 1, 2010 at 4:40 AM, Alan Hodgson wrote:
> On Monday 31 May 2010, Devrim Gündüz wrote:
>> On Mon, 2010-05-31 at 21:14 +0530, Nilesh Govindarajan wrote:
>> > if you install some libraries like python clients or some
>> > software depending on PgSql from the repositories in RPM/DPKG base
Hello
In my environment,archive_command works fine with this command.
archive_command = 'COPY %p C:\\Program
Files\\PostgreSQL\\8.4\\data\\archive\\%f'
(Is this what you want to know?)
> Where can I find an example shell script and windows batch file for
> archive_command for backup?
>
> Tha
On Monday 31 May 2010, Devrim Gündüz wrote:
> On Mon, 2010-05-31 at 21:14 +0530, Nilesh Govindarajan wrote:
> > if you install some libraries like python clients or some
> > software depending on PgSql from the repositories in RPM/DPKG based
> > OS, you will have a tough time with the dependency s
From: Ashesh Vashi
Sent: Monday, May 31, 2010 11:33 AM
To: Bob Pawley
Cc: Postgresql ; adrian.kla...@gmail.com
Subject: Re: Installing version 8.4
Hi Bob,
On Mon, May 31, 2010 at 10:57 PM, Bob Pawley wrote:
During the install it was recommended that I run the scripts at
PostgresPlus
I am having difficulties. I have rerun my update that uses the python
functions..
(1) UPDATE nlpg.match_data SET org = normalise(org);
And some other similar queries on neighbouring fields in the table. They
have all now worked. Without any changes to the configuration. I have
done one thing
On 31 May 2010, at 23:27, wrote:
> Hi,
>
> I'm just try to insert or update an actually table with Microsoft .NET
> platform VS2005.
>
> The problem is that de "\" dissapear when I make the insert or Update.
Postgres is interpreting those backslashes as escape characters. Either escape
the
Hi,
I'm just try to insert or update an actually table with Microsoft .NET platform
VS2005.
The problem is that de "\" dissapear when I make the insert or Update.
If i debug the object has all detailed path...so Why is not saved on the table.
The type of column is character (100).
So:
I have:
On 05/31/2010 02:45 PM, Isabella Ghiurea wrote:
> I 'm looking for some tip, advice to improve PG backups performance,
Yep, I thought I recalled a conversation like this before, this might have some
interesting info:
http://archives.postgresql.org/pgsql-performance/2010-03/msg00132.php
On 05/31/2010 02:45 PM, Isabella Ghiurea wrote:
Hi Andy,
Thank you , please, see bellow my answers:
Andy Colson wrote:
On 05/31/2010 11:05 AM, Isabella Ghiurea wrote:
> Hello PG list,
> I 'm looking for some tip, advice toimprove PG backups performance,
> presently running
> pg_dumpall compres
Hi Andy,
Thank you , please, see bellow my answers:
Andy Colson wrote:
On 05/31/2010 11:05 AM, Isabella Ghiurea wrote:
> Hello PG list,
> I 'm looking for some tip, advice toimprove PG backups performance,
> presently running
> pg_dumpall compressed option on raid array 0 getting aprox14GB writ
On 05/31/2010 11:00 AM, Wappler, Robert wrote:
Hi list,
I want to create an install script for a database. First a schema and
its elements are created in a second approach, some adjustments are
done, e.g. create rows, which can be referenced as defaults instead of
having NULL in the referenced co
On 05/31/2010 11:05 AM, Isabella Ghiurea wrote:
Hello PG list,
I 'm looking for some tip, advice toimprove PG backups performance,
presently running
pg_dumpall compressed option on raid array 0 getting aprox14GB writes in
45 min, I'm backing up aprox 200GB database cluster daily .
How can I impro
On Mon, 2010-05-31 at 01:29 -0700, Michal Szymanski wrote:
> Currently we use Debian, but it chosen by our OS admnistrator. Now we
> can change our OS and it is question what Linux edition will be the
> best. We would like have access to new versions of Postgres as soon
> as possible, for Debian s
On Mon, 2010-05-31 at 08:47 -0600, Scott Marlowe wrote:
> Pgsql is pretty easy to build from source.
Right, but some sysadmins don't want to see development libraries on the
machines.
--
Devrim Gündüz
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to you
On Mon, 2010-05-31 at 21:14 +0530, Nilesh Govindarajan wrote:
> if you install some libraries like python clients or some
> software depending on PgSql from the repositories in RPM/DPKG based
> OS, you will have a tough time with the dependency stuff.
Really?
--
Devrim Gündüz
--
Sent via p
Hi Bob,
On Mon, May 31, 2010 at 10:57 PM, Bob Pawley wrote:
> During the install it was recommended that I run the scripts at
> PostgresPlus\8.4ss\share\PostgreSQL\contrib
>
You should run the script against the output of "pg_config.exe --sharedir",
which should be "C:\Program Files (x64)\Postg
Jun Wang wrote:
> Where can I find an example shell script and windows batch file for
> archive_command for backup?
There are no examples. I can be any command you want, like 'COPY'.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
Where can I find an example shell script and windows batch file for
archive_command for backup?
Thanks.
Jack
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
During the install it was recommended that I run the scripts at
PostgresPlus\8.4ss\share\PostgreSQL\contrib
The folder contrib is present holding 78 files. But the PostgreSQL folder is
missing.
Perhaps, that may be of some help?
Also I got the same error on my other computer that is running Win
On Mon, 31 May 2010 17:23:51 +0200
Szymon Guz wrote:
> > Yeah it is. But what is it going to be an upgrade process? On a
> > production box?
> > Any experience to share on upgrading from source on Debian?
> Usually that's pretty easy: for upgrading the minor version (e.g.
> from 8.3.1 to 8.3.3)
> "TL" == Tom Lane writes:
TL> Viktor Pavlenko writes:
>> I'm using PG 8.1.11 on linux and having trouble inserting a
>> timestamp value (for starters :)) from a C++ program.
TL> The first argument of to_timestamp is not a timestamp ...
TL> regar
Viktor Pavlenko writes:
> I'm using PG 8.1.11 on linux and having trouble inserting a timestamp
> value (for starters :)) from a C++ program.
The first argument of to_timestamp is not a timestamp ...
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-genera
=?iso-8859-1?Q?Alonso_Garc=EDa_=2C_Bruno_Elier?= writes:
> Yes. If I use PQexec, both 7.4 and 8.3 produce a quick result but I if I use
> asynchronous command processing 8.3 produce a slow result whereas 7.4 works
> fine.
You're still being quite unclear. Is this 7.4 libpq + 7.4 server
against
On Mon, May 31, 2010 at 8:17 PM, Scott Marlowe wrote:
> On Mon, May 31, 2010 at 2:29 AM, Michal Szymanski
> wrote:
>> Hi,
>> Currently we use Debian, but it chosen by our OS admnistrator. Now we
>> can change our OS and it is question what Linux edition will be the
>> best. We would like have ac
Hello,
I'm using PG 8.1.11 on linux and having trouble inserting a timestamp
value (for starters :)) from a C++ program.
The table:
CREATE TABLE test_tbl (ts TIMESTAMP (6) NOT NULL);
Insert works from psql:
INSERT INTO test_tbl VALUES (to_timestamp('20100527101705806216',
'MMDDHHMISSUS'))
>So PQexec works fine for you on both 7.4 and 8.3, producing a quick
>result no matter which server you run it against?
Yes. If I use PQexec, both 7.4 and 8.3 produce a quick result but I if I use
asynchronous command processing 8.3 produce a slow result whereas 7.4 works
fine.
>Consider using
Hello PG list,
I 'm looking for some tip, advice toimprove PG backups performance,
presently running
pg_dumpall compressed option on raid array 0 getting aprox14GB writes
in 45 min, I'm backing up aprox 200GB database cluster daily .
How can I improve this performance with the present hardwar
Le lundi 31 mai 2010 10:23:51, Szymon Guz a écrit :
> 2010/5/31 Ivan Sergio Borgonovo
>
> > On Mon, 31 May 2010 08:47:25 -0600
> >
> > Scott Marlowe wrote:
> > > On Mon, May 31, 2010 at 2:29 AM, Michal Szymanski
> > >
> > > wrote:
> > > > Hi,
> > > > Currently we use Debian, but it chosen by
Hi list,
I want to create an install script for a database. First a schema and
its elements are created in a second approach, some adjustments are
done, e.g. create rows, which can be referenced as defaults instead of
having NULL in the referenced column. Below is a minimum non-working
example.
Th
Am 31.05.2010 17:44, schrieb Tom Lane:
Richard Broersma writes:
On Mon, May 31, 2010 at 7:48 AM, Jan Strube wrote:
I accidentally encountered a feature in Postgres 8.3 that I couldn't find in
the documentation while submitting a query like
SELECT my_table.varchar FROM my_table
wh
Richard Broersma writes:
> On Mon, May 31, 2010 at 7:48 AM, Jan Strube wrote:
>> I accidentally encountered a feature in Postgres 8.3 that I couldn't find in
>> the documentation while submitting a query like
>>
>> SELECT my_table.varchar FROM my_table
>>
>> which returns a concatenated string
You should use whatever you are comfortable with.
I would go with ArchLinux for its ease of use and making packages. RPM
and DPKG are much harder to build than ArchLinux's .pkg.tar.xz
Also, if you install some libraries like python clients or some
software depending on PgSql from the repositories i
Ivan Sergio Borgonovo writes:
> On Mon, 31 May 2010 08:47:25 -0600
> Scott Marlowe wrote:
>> Pgsql is pretty easy to build from source.
> Yeah it is. But what is it going to be an upgrade process? On a
> production box?
If it makes you feel better, build your own RPMs (or
$package-style-of-choi
On Mon, May 31, 2010 at 7:48 AM, Jan Strube wrote:
> I accidentally encountered a feature in Postgres 8.3 that I couldn't find in
> the documentation while submitting a query like
>
> SELECT my_table.varchar FROM my_table
>
> which returns a concatenated string of all field values per row.
> I wo
2010/5/31 Ivan Sergio Borgonovo
> On Mon, 31 May 2010 08:47:25 -0600
> Scott Marlowe wrote:
>
> > On Mon, May 31, 2010 at 2:29 AM, Michal Szymanski
> > wrote:
> > > Hi,
> > > Currently we use Debian, but it chosen by our OS admnistrator.
> > > Now we can change our OS and it is question what Li
On Mon, 31 May 2010 08:47:25 -0600
Scott Marlowe wrote:
> On Mon, May 31, 2010 at 2:29 AM, Michal Szymanski
> wrote:
> > Hi,
> > Currently we use Debian, but it chosen by our OS admnistrator.
> > Now we can change our OS and it is question what Linux edition
> > will be the best. We would like h
Hello,
I accidentally encountered a feature in Postgres 8.3 that I couldn't
find in the documentation while submitting a query like
SELECT my_table.varchar FROM my_table
which returns a concatenated string of all field values per row.
I wonder where this is documented (and if it has something
2010/5/31 Michal Szymanski
> Hi,
> Currently we use Debian, but it chosen by our OS admnistrator. Now we
> can change our OS and it is question what Linux edition will be the
> best. We would like have access to new versions of Postgres as soon
> as possible, for Debian sometimes we had to wait
Michal Szymanski wrote:
> Hi,
> Currently we use Debian, but it chosen by our OS admnistrator. Now we
> can change our OS and it is question what Linux edition will be the
> best. We would like have access to new versions of Postgres as soon
With which distribution you are familiar?
> as poss
On 31/05/2010 10:34 PM, Alonso García , Bruno Elier wrote:
> If I perform the query using pgadmin I get the same result in both
versions 7.4 and version 8.3.
Just re-read your post and realized you were probably saying that you
get (effectively) the same EXPLAIN ANALYZE results from both, ie
On Mon, May 31, 2010 at 2:29 AM, Michal Szymanski wrote:
> Hi,
> Currently we use Debian, but it chosen by our OS admnistrator. Now we
> can change our OS and it is question what Linux edition will be the
> best. We would like have access to new versions of Postgres as soon
> as possible, for Deb
On Mon, May 31, 2010 at 1:59 PM, Michal Szymanski wrote:
> Hi,
> Currently we use Debian, but it chosen by our OS admnistrator. Now we
> can change our OS and it is question what Linux edition will be the
> best. We would like have access to new versions of Postgres as soon
> as possible, for Deb
On 31/05/2010 10:34 PM, Alonso García , Bruno Elier wrote:
If I perform the query using pgadmin I get the same result in both versions 7.4
and version 8.3.
Please post the output of EXPLAIN ANALYZE for each. See:
http://wiki.postgresql.org/wiki/SlowQueryQuestions
and
http://wiki.postgr
Hi,
Currently we use Debian, but it chosen by our OS admnistrator. Now we
can change our OS and it is question what Linux edition will be the
best. We would like have access to new versions of Postgres as soon
as possible, for Debian sometimes we had to wait many weeks for
official packages.
Rega
>> With that analysis, I'd be betting against it being a client problem.
>> (If you wanted, you might confirm that by pointing an old client at
>> the new server.)
>>
>> I'd look into how the data was loaded into the new server and how
>> the database is configured: number of buffers, indexes, and
On 31/05/2010 5:41 PM, Giles Lean wrote:
=?iso-8859-1?Q?Alonso_Garc=EDa_=2C_Bruno_Elier?= wrote:
And the problems I am finding are the following:
->Queries from the client to the new DB server take a lot of time.
->Queries from the client to the old DB server are fast.
->The same query takes 1
On 2010-05-26, John Gage wrote:
> Please forgive this intrusion, and please ignore it, but how many
> applications out there have 110,000,000 row tables? I recently
> multiplied 85,000 by 1,400 and said now way Jose.
census data would be one.
USA phone whitepages.
transaction records at a me
=?iso-8859-1?Q?Alonso_Garc=EDa_=2C_Bruno_Elier?= wrote:
> And the problems I am finding are the following:
> ->Queries from the client to the new DB server take a lot of time.
> ->Queries from the client to the old DB server are fast.
> ->The same query takes 150 secs in one case an 1 sec in the
Hello,
I am migrating a client/server application from Debian Sarge to Debian 5.0 and
I am finding problems with the client application. The facts are the following:
->The client application is an interface to a Postgresql DB so it uses libpq.
->The client application compiles properly in both Deb
On 2010-05-30, Martin Gainty wrote:
> i have mixed feelings about parameterised statements.
>
> On the one hand a parameterised statement would be more
> difficult for a Wireshark criminal to insert their own c**p
> into a database because they would have to know the schema
> a-priori for exampl
71 matches
Mail list logo
