Bruce Momjian <[EMAIL PROTECTED]> writes:
> What is in the 7.2.X CVS that we would want to release?
CVS logs show the following as post-7.2.1 changes in REL7_2_STABLE branch.
Draw your own conclusions ...
regards, tom lane
2002-06-15 14:38 tgl
* src/backend/ut
What is in the 7.2.X CVS that we would want to release?
---
Tom Lane wrote:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> >> Yeah. This is fixed in current sources, and I back-patched it into
> >> the REL7_2 br
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> Yeah. This is fixed in current sources, and I back-patched it into
>> the REL7_2 branch, but current plans don't seem to include a 7.2.2
>> release --- we'll be going straight to 7.3 beta instead.
> Is it worth doing a 7.2.2 patch that wil
> Yeah. This is fixed in current sources, and I back-patched it into
> the REL7_2 branch, but current plans don't seem to include a 7.2.2
> release --- we'll be going straight to 7.3 beta instead.
Is it worth doing a 7.2.2 patch that will dump people's foreign keys as
ALTER TABLE/ADD FOREIGN KEY
"Kristian Eide" <[EMAIL PROTECTED]> writes:
> There seems to be a bug when dumping a view which is a UNION of selects, one
> of which has an ORDER BY. A pair of paranthesises around the select is
> missing, and this cause a subsequent restore to fail.
Yeah. This is fixed in current sources, and
Oh, sure I understand. There were a number of people mentioning the
core issue. What the core/major folks do is more give information about
historical or practical ideas behind certain issues, so in that way they
do have a strong voice, but only in the way their ideas effect other
people's opin
Kristian Eide wrote:
> Thanks, very helpful, although there does not seem to be much description of
> what the two free space map options in postgresql.conf actually do. Doing a
> VACUUM ANALYZE VERBOSE on my largest table gives me:
>
> NOTICE: Pages 43681: Changed 208, Empty 0; Tup 1921387: Vac
Mallah,
> do you need
> http://www.postgresql.org/idocs/index.php?monitoring-stats.html ?
Yes, thank you! That was exactly what I was looking for.
-Josh Berkus
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an app
> You should also search the archives for threads on free space maps. You
> most likely need to increase yours. In particular, see:
>http://archives.postgresql.org/pgsql-general/2002-07/msg00972.php
Thanks, very helpful, although there does not seem to be much description of
what the two free
Kristian Eide wrote:
> This is not good as the database is in use 24/7, and without the indexes
> everything comes to a screeching halt. This means I probably will have to
> stop the programs using the database for the time it takes to re-create the
> indexes; this is better than having to dump/re
> In my case, it was the fact that indexes don't release the space of
> indexes of deleted rows. So, if you have a table that has a lot of
> inserts/deletes, your indexes will grow incredibly fast.
>
> The way to see what your biggest items are:
> select * from pg_class order by relpages desc;
Y
I've run into this myself. Tom lane helped me out.
In my case, it was the fact that indexes don't release the space of
indexes of deleted rows. So, if you have a table that has a lot of
inserts/deletes, your indexes will grow incredibly fast.
The way to see what your biggest items are:
selec
There seems to be a bug when dumping a view which is a UNION of selects, one
of which has an ORDER BY. A pair of paranthesises around the select is
missing, and this cause a subsequent restore to fail. This is quite annoying
as the backup file must be manually edited before it can be restored, and
Hi, I have a PostgreSQL 7.2.1 database which normally (just after a
pg_restore) takes about 700-800MB of disk space. Now, the problem is that
the database grows quite quickly when in use, although we don't put very
much data in. Granted, there is quite a few records deleted and inserted,
but the t
On Sat, 3 Aug 2002, Marc SCHAEFER wrote:
> is there any replacement so that inserting somewhere acts on multiple
> tables ?
Thanks for the suggestion to use RULES.
My solution (comments welcome):
DROP RULE r_entree_rapide_ecriture_insert;
DROP FUNCTION f_entree_rapide_ecriture_insert(TEXT,
do you need
http://www.postgresql.org/idocs/index.php?monitoring-stats.html ?
Folks,
>
> Can anyone point me to documentation on the new STATISTICS features of 7.2? I can't
>seem to
> find anything in the online docs, except the barest mention of ALTER TABLE SET
>STATISTICS
> (which doesn't
Folks,
Can anyone point me to documentation on the new STATISTICS features of
7.2? I can't seem to find anything in the online docs, except the
barest mention of ALTER TABLE SET STATISTICS (which doesn't explain
what to do with the info).
-Josh Berkus
---(end of broadca
Marc SCHAEFER <[EMAIL PROTECTED]> writes:
> at least with PostgreSQL 7.1 it was possible to create a trigger on a
> view.
Use a rule instead. 7.2 will reject an attempt to insert into a view
without a replacement rule, so a trigger would do you no good anyhow.
(I thought that behavior went back
Marc,
> at least with PostgreSQL 7.1 it was possible to create a trigger on a
> view. 7.2 seems to fail with:
>
>psql:t:25: ERROR: CreateTrigger: relation "egg_view" is not a
> table
>
> is there any replacement so that inserting somewhere acts on multiple
> tables ?
Yes. Use the RULES s
Hi,
at least with PostgreSQL 7.1 it was possible to create a trigger on a
view. 7.2 seems to fail with:
psql:t:25: ERROR: CreateTrigger: relation "egg_view" is not a table
is there any replacement so that inserting somewhere acts on multiple
tables ?
Thank you.
Code reference: (stupid, re
Bruce,
> I have seen a few mentions in the past weeks about core vs. non-core
> developers. I should reiterate that the core group feels there is no
> distinction between the opinions of the core people and the other
> major
> developers. Everyone gets just one vote.
Which is why it's importan
That's what your crontab is for.
Chris
- Original Message -
From: "Wei Weng" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, August 03, 2002 5:40 AM
Subject: [SQL] What about this?
> Why can't postmaster run VACUUM ANALYZE automatically every once in a
> while? Since it is
> I'm running into a performance problem when considering the following
> scenario: I have a fairly large table (1mio rows) related to other smaller
> tables (between 100 and 1 rows) and would like to retrieve the joined
> data (through a view) in random order. In order to do so, the main tabl
23 matches
Mail list logo
