Neil Conway wrote:
On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote:
Nothing except initdb should add objects in pg_catalog. AFAICS,
adminpack doesn't have any special requirements, so it should behave
like all other contrib modules.
Where are we on this? When this topic was last
On Sun, 2006-11-05 at 15:02 +, Simon Riggs wrote:
Code comments now discuss relative paths also.
Patch containing just the minor cleanup of docs and code comments.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Index: doc/src/sgml/backup.sgml
Dear Stefan Kaltenbrunner,
dear PostgreSQL gurus,
current_user returns a name (currently, 64 bytes of data); I felt it would
be contrary to good database practice to repetitiously include (up to) 64
bytes of data in each and every row of each and every table instead of making
use of what
Tom Lane wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
My first impulse was to just append a (disabled) after each
disabled trigger, but perhaps that is not visually obvious enough,
especially if the table has many triggers on it.
Agreed, but maybe put it up at the front?
Triggers:
Peter Eisentraut [EMAIL PROTECTED] writes:
Jim C. Nasby wrote:
Since installing python 2.5, tapir has been failing:
I have removed the use of the deprecated whrandom module, which should
take care of one regression test failure, but after that I get
*** glibc detected *** free(): invalid
On Mon, 2006-11-06 at 09:02 +, Dave Page wrote:
Neil Conway wrote:
On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote:
Nothing except initdb should add objects in pg_catalog. AFAICS,
adminpack doesn't have any special requirements, so it should behave
like all other contrib
Simon Riggs [EMAIL PROTECTED] writes:
At the moment we only allow 2 types of table. Approved core catalog
tables and user tables.
ISTM we need 3 types of tables, with the additional type being add-on
system functionality, such as adminpack,
What? The adminpack module only creates functions.
head does this to me when I try to initdb:
[EMAIL PROTECTED]:~$ /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
The files belonging to this database system will be owned by user postgres.
This user must also own the server process.
The database cluster will be initialized with locale
Matt Miller [EMAIL PROTECTED] writes:
head does this to me when I try to initdb:
I bet you didn't do a full recompile after cvs update.
If you're not using --enable-depend then you really have
to do make clean or even make distclean.
regards, tom lane
On Mon, 2006-11-06 at 13:37 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
At the moment we only allow 2 types of table. Approved core catalog
tables and user tables.
ISTM we need 3 types of tables, with the additional type being add-on
system functionality, such as
head does this to me when I try to initdb:
I bet you didn't do a full recompile after cvs update.
If you're not using --enable-depend then you really have
to do make clean or even make distclean.
I am using --enable-depend, but I'll make clean and give
it another shot.
head does this to me when I try to initdb:
...
do make clean or even make distclean.
I am using --enable-depend, but I'll make clean and give
it another shot.
All better. Thanks.
I guess I be suspicious of --enable-depend for a while.
---(end of
head does this to me when I try to initdb:
I bet you didn't do a full recompile after cvs update.
If you're not using --enable-depend then you really have
to do make clean or even make distclean.
I am using --enable-depend, but I'll 'make clean' and give
it another shot.
Due to popular demand (1 person), I've compared sizes with 90 and 100
fillfactors, along with using the new GIN index.
Findings were not surprising, except for the GIN indexes, which doubled in
size.
After several ALTER/RE INDEXes, here they are:
GiST
8.1 = 94990
8.2 FF90 = 106244
EnterpriseDB has been running a research project to improve the
performance of heavily updated tables. We have a number of approaches
prototyped and we'd like to discuss the best of these now on -hackers
for community input and patch submission to PostgreSQL core.
The most important step with any
One issue is that I'm not sure think you've got your sugar quite right.
Have you tested with:
(col IS NOT NULL AND 123 IS NOT NULL AND col = 123) OR
(col IS NULL and 123 IS NULL) ?
It's possible that the planner doesn't know about using an index for
DISTINCT; or it might just want an index
Hi,
This is Andrew with ProV International.
I have
direct client requirement for the position of PostGre Database Developer
at San Diego, CA. For you reference given below is the
requirement.If you find this interesting and matching to skills then
please send across your updated resume
On Mon, Nov 06, 2006 at 09:12:32AM -0500, Andrew Dunstan wrote:
Tom Lane wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
My first impulse was to just append a (disabled) after each
disabled trigger, but perhaps that is not visually obvious enough,
especially if the table has many triggers
Simon,
Bring it on! We at GP have been evaluating various approaches to index
organized tables which unify index with heap storage to solve some of
the problems you mention. Split index and heap is a big issue in
Postgres and we'd all welcome a good solution to it, even for limited
Andrew,
I have direct client requirement for the position of PostGre Database
Developer at San Diego, CA. For you reference given below is the
requirement. If you find this interesting and matching to skills then
please send across your updated resume in word format ASAP. If you have
any
On Sun, Nov 05, 2006 at 09:53:08PM +0100, Martijn van Oosterhout wrote:
Note that the constructs:
ARRAY['a',NULL,'c']
and
'{a,NULL,c}'
are *completely* different. The first is a special array constructor
and all its parameters are normal SQL expressions, so you can reference
columns
Simon Riggs wrote:
EnterpriseDB has been running a research project to improve the
performance of heavily updated tables. We have a number of approaches
prototyped and we'd like to discuss the best of these now on -hackers
for community input and patch submission to PostgreSQL core.
This shows all three forms to be equivalent.
SELECT
exp1,
exp2,
exp1 IS NOT DISTINCT FROM exp2 AS isnotdistinct,
exp1 is not null and exp2 is not null and exp1 = exp2 or exp1 is null and
exp2 is null AS JP,
(exp1 is not null and exp2 is not null and exp1 = exp2) or (exp1 is null
and
Simon Riggs [EMAIL PROTECTED] wrote:
EnterpriseDB has been running a research project to improve the
performance of heavily updated tables. We have a number of approaches
prototyped and we'd like to discuss the best of these now on -hackers
for community input and patch submission to
As discussed briefly on pgsql-hackers, the current psql \d command
does not make any distinction between enabled and disabled triggers.
The attached patch modifies psql's describeOneTableDetails() such that
triggers and disabled triggers are displayed as two separate footer
lists, for example:
On 11/7/06, Brendan Jurd [EMAIL PROTECTED] wrote:
As discussed briefly on pgsql-hackers, the current psql \d command
does not make any distinction between enabled and disabled triggers.
The attached patch modifies psql's describeOneTableDetails() such that
triggers and disabled triggers are
On Tue, 2006-11-07 at 13:02 +0900, ITAGAKI Takahiro wrote:
Simon Riggs [EMAIL PROTECTED] wrote:
EnterpriseDB has been running a research project to improve the
performance of heavily updated tables. We have a number of approaches
prototyped and we'd like to discuss the best of these now
While I was poking around in src/bin/psql/describe.c, I noticed that
when the query for inherited tables is opened, the code checks whether
the result is valid and if not, it goes straight to the error_return,
without clearing result sets that may have been open at the time. See
line 1174 in
Brendan Jurd [EMAIL PROTECTED] writes:
Is it crucial that result sets be cleared before going out of scope?
It sounds like it'd leak memory inside psql; but realistically that's
probably not an enormous problem for this usage. How much uglification
of the code are we talking about to fix it?
On 11/7/06, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
Is it crucial that result sets be cleared before going out of scope?
It sounds like it'd leak memory inside psql; but realistically that's
probably not an enormous problem for this usage. How much
30 matches
Mail list logo
