Bruce Momjian wrote:
You didn't like server_min_messages = 'notify'?
I merely don't have a feeling for how much additional stuff
verbose would be putting in the log files.
If it's a good practice for production systems to be logging
NOTIFY's I'm happy with the change.
My reasoning why I thought the
On Sun, 13 Mar 2005 02:59 pm, Bruno Wolff III wrote:
> On Sat, Mar 12, 2005 at 23:05:41 +0200,
> Andrus Moor <[EMAIL PROTECTED]> wrote:
> > I have table containing different types of documents (type A, B and C).
> >
> > Each document type must have separate sequential ID starting at 1
> >
> > I
Ron Mayer wrote:
> Well, I was really hoping something would end up in the log file.
>
> The situation is that our clients - sometimes not that computer
> savvy - go perhaps a year without us being involved (unless
> the log monitoring scripts show something abnormal; or if the
> system breaks).
>
Well, I was really hoping something would end up in the log file.
The situation is that our clients - sometimes not that computer
savvy - go perhaps a year without us being involved (unless
the log monitoring scripts show something abnormal; or if the
system breaks).
The primary motivation for twea
Martijn van Oosterhout writes:
> Note, the planner does have most of the intelligence needed to
> determine when it can skip a partition.
The issue isn't really whether the planner *could* use a constraint
to decide that a table need not be scanned at all. As you say, we
have practically all the
On Sat, Mar 12, 2005 at 23:05:41 +0200,
Andrus Moor <[EMAIL PROTECTED]> wrote:
> I have table containing different types of documents (type A, B and C).
>
> Each document type must have separate sequential ID starting at 1
>
> ID of first inserted record of type A must be set to 1
> ID of first
Shutdown postgresql, delete everything under /var/lib/pgsql/ and then
start postgresql again.
On Sat, 12 Mar 2005 16:51:55 -0800, bruce <[EMAIL PROTECTED]> wrote:
> so.. what can i just delete and keep going forward. the old version was
> never really used, and we don't have an old version of the
Hi all,
is there on the net any general howto on SQL query optimizations? We
have recently moved our project from MySQL to PostgreSQL and are having
problem with one of our queries. The EXPLAIN command is surely useful
but I don't know how to read it and how to use the output to optimize
the qu
On Sun, 13 Mar 2005 00:18:39 +0100, Martijn van Oosterhout
wrote:
> On Sat, Mar 12, 2005 at 08:24:20PM +, Mike Rylander wrote:
> > There is now way to have PG completely skip the unused partitions.
> > However, with an index on the "partitioner" column of each partition
> > table PG will basic
so.. what can i just delete and keep going forward. the old version was
never really used, and we don't have an old version of the postgres app..
thanks
bruce
-Original Message-
From: Lonni J Friedman [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 12, 2005 3:30 PM
To: [EMAIL PROTECTED]
On Sat, 12 Mar 2005 10:13:34 -0800, bruce <[EMAIL PROTECTED]> wrote:
> hi...
>
> i get a postgres error when i've gone from RH8 to FC3 and am now using
> postgreSQL-7.4.7.
>
> an err msg 'an old version of database format was found. you need to upgrade
> the data format."
>
> searching googl
On Sat, Mar 12, 2005 at 08:24:20PM +, Mike Rylander wrote:
> There is now way to have PG completely skip the unused partitions.
> However, with an index on the "partitioner" column of each partition
> table PG will basically fall of the end of the index almost
> imediately, and then use an app
On Sat, Mar 12, 2005 at 12:22:38PM -0500, Randall Nortman wrote:
>
> Anyway, afaik, Postgres does not store the "original" timezone
> anywhere, and so could not possibly retrieve it. I think the only
> physical difference between the "timestamp" and "timestamp with time
> zone" types is in the sy
Vitaly Belman wrote:
> Is it possible to ALTER somehow an object and move it from schema to
> schema? It really sucks to drop an object completely for such a change
> (because of all the object relations forcing me to drop them first and
> then to recreate).
Our TODO has:
o Allow objects
Is it possible to ALTER somehow an object and move it from schema to
schema? It really sucks to drop an object completely for such a change
(because of all the object relations forcing me to drop them first and
then to recreate).
--
ICQ: 1912453
AIM: VitalyB1984
MSN: [EMAIL PROTECTED]
Yahoo!:
Hi Everyone
Im trying to log each DB to a different file.
So I added:
log_line_prefix ='%d :'
To the postgresql.conf
Later using syslog-ng i added a rule to redirect local0 + postgres + 'DB
Name' to specific file.
But sadly that didnt worked as its only work on one line queries.
every select cons
I have table containing different types of documents (type A, B and C).
Each document type must have separate sequential ID starting at 1
ID of first inserted record of type A must be set to 1
ID of first inserted record of type B must be also set to 1
ID of second record of type A must be set to
On Sat, 12 Mar 2005 17:39:38 +0100 (CET), Christian Kratzer
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Sat, 12 Mar 2005, Mike Rylander wrote:
>
> > Back to the original question on this thread, and using PG 8.0.1.
> > Perhaps someone would like to poke holes in this (other than the need
> > to set u
On Sat, 2005-03-12 at 15:00 -0500, Reuben D. Budiardja wrote:
> Hello,
> Oracle has a concept of Database link, IE you can access data from a table in
> different database, even if the database is in different host, using
> something like
>
> SELECT * FROM [EMAIL PROTECTED];
>
> Is there someth
Hello,
Oracle has a concept of Database link, IE you can access data from a table in
different database, even if the database is in different host, using
something like
SELECT * FROM [EMAIL PROTECTED];
Is there something similar in PostgreSQL? I would like to know if I can access
my data on a
Randall Nortman <[EMAIL PROTECTED]> writes:
> Anyway, afaik, Postgres does not store the "original" timezone
> anywhere, and so could not possibly retrieve it. I think the only
> physical difference between the "timestamp" and "timestamp with time
> zone" types is in the system catalog; the manual
hi...
i get a postgres error when i've gone from RH8 to FC3 and am now using
postgreSQL-7.4.7.
an err msg 'an old version of database format was found. you need to upgrade
the data format."
searching google shows that others have seen this, but i can't find a way to
correct it. i've checked
On Sat, Mar 12, 2005 at 05:44:52PM +0100, Karsten Hilbert wrote:
> On Fri, Mar 11, 2005 at 01:43:21PM -0500, Randall Nortman wrote:
>
> > As others have mentioned, store timestamps on the server in UTC,
>
> 1) As long as I store them as I should
> not need to care what they are stored as on the
On Fri, Mar 11, 2005 at 01:43:21PM -0500, Randall Nortman wrote:
> As others have mentioned, store timestamps on the server in UTC,
1) As long as I store them as I should
not need to care what they are stored as on the backend as
long as I provide the proper timezone for the client location.
Cor
"vinita bansal" <[EMAIL PROTECTED]> writes:
> Also, a particular query which was taking a min or less with postgres 7 is
> taking 15 mins now.
> Here is the query plan for the query both for postgres 7.4.6 and postgres 8:
It's hard to say anything about this when you only provided EXPLAIN and
not
Hi,
On Sat, 12 Mar 2005, Mike Rylander wrote:
Back to the original question on this thread, and using PG 8.0.1.
Perhaps someone would like to poke holes in this (other than the need
to set up fkeys and indexes on the inherited tables...):
"vinita bansal" <[EMAIL PROTECTED]> writes:
> Can you please provide details on the relationship between work_mem and
> maintenance_work_mem (Postgres doc specifies that the value for maintenance
> work_mem should be larger but I am not clear on why that should be so)
Because the other way doesn
On Sat, Mar 12, 2005 at 10:41:08 +,
ILove TheSpam <[EMAIL PROTECTED]> wrote:
> Lets say I have 3 tables:
>
> surnames - surnameid serial (Primary Key), surname varchar (Unique)
> firstnames - firstnameid serial (Primary Key), firstname varchar (Unique)
> users - userid serial (Primary Key),
On Sat, Mar 12, 2005 at 11:30:03 +0100,
"Leif B. Kristensen" <[EMAIL PROTECTED]> wrote:
>
> In MySQL, the checking on dates is very relaxed, so it's totally legal
> to enter a date as '1731-00-00', and let your own program logic decide
> that this means just the year 1731. Do I have to make my
Back to the original question on this thread, and using PG 8.0.1.
Perhaps someone would like to poke holes in this (other than the need
to set up fkeys and indexes on the inherited tables...):
---
begin;
create schema pa
Hi,
- Oops, forgot to mention that!!
It is Redhat Linux and storage system is SCSI. Also it has 4 processors.
- I would say that there is no particular reason for using a particular
setting except that there were no memory constraints in my case and
they seem to work fine with Postgres 7.4.
Hi Madison,
When you migrate from PG7.2 to PG7.4 didn't you change the Perl too.
When we migrate the PG, we also change the OS verison and the Perl and
etc. So this may be Perl migration error. We have some in our own
scripts (from the same type you posted). As Ian says, you should check
the Pe
Something even more peculiar (at least it seems to me..)...
If I drop the index table1_category_gist_idx, I get this:
jobs=> explain analyze select id from table1 where category <@ 'a.b'
ORDER BY category;
QUERY PLAN
I have a rather peculiar performance observation and would welcome any
feedback on this.
First off, the main table (well, part of it.. it is quite large..):
Table "table1"
Column | Type |
Could you describe the problem you're trying to solve? It might
be easier to help if we knew the ultimate purpose of what you're
trying to do. Something like "I want to do this because"
Sure.
Lets say I have 3 tables:
surnames - surnameid serial (Primary Key), surname varchar (Unique)
firstna
Hello all,
this is my first posting to this list. I have been using MySQL for a few
years with a web application for displaying my genealogy database, a
FoxPro database from The Master Genealogist from which I'm dumping a
subset with a Perl script and the DBD::XBase module. I'm now in the
proce
On Sat, 2005-03-12 at 00:13 -0800, Benjamin Smith wrote:
> Given the tables defined below, what's the easiest way to check for schedule
> conflicts?
>
> So far, the only way I've come up with is to create a huge, multi-dimensional
> array in PHP, with a data element for every minute of all time
On Fri, 2005-03-11 at 17:52 +, Brian Gunning wrote:
[rearranged quoting]
> From: [EMAIL PROTECTED]
> --- William Shatner <[EMAIL PROTECTED]> wrote:
> > I have recently migrated from MS Access to
> > PostgreSQL.Previously I had
> > a SQL command
> >
> > ResultSet aGroupResultSet =
> > a
On Sat, 12 Mar 2005 02:18:55 -0500, Madison Kelly <[EMAIL PROTECTED]> wrote:
> Hi all,
>
>I am back to trying to get the forum software called 'Ikonboard'
> working under postgres (it's advertised as being supported but the
> developers confirmed their pgSQL person left a while back).
>
>
Given the tables defined below, what's the easiest way to check for schedule
conflicts?
So far, the only way I've come up with is to create a huge, multi-dimensional
array in PHP, with a data element for every minute of all time taken up by
all events, and then check for any of these minutes t
40 matches
Mail list logo
