Hi all,
Am experimenting to find out what kind of performance gain are achieved
from moving indexes to a different scsi drives than the WAL files, than
the data itself, etc.
Have come across an interesting problem.
Have moved the indexes to another drive, then created symlinks to them.
Ran a
On 28 Sep 2002 at 17:08, Justin Clift wrote:
Have moved the indexes to another drive, then created symlinks to them.
Ran a benchmark against the database, REINDEX'd the tables, VACUUM FULL
ANALYZE'd, prepared to re-run the benchmark again and guess what?
The indexes were back on the
Shridhar Daithankar wrote:
snip
Looks like we should have a subdirectory in database directory which stores
index.
That was my first thought also, but an alternative/additional approach
would be this (not sure if it's workable):
- As each index already has a bunch of information stored
On 28 Sep 2002 at 17:51, Justin Clift wrote:
Shridhar Daithankar wrote:
snip
Looks like we should have a subdirectory in database directory which stores
index.
That was my first thought also, but an alternative/additional approach
would be this (not sure if it's workable):
- As
Jim Mercer writes:
ideally, i'd like to have users-per-database, as opposed to the global
model we have now.
That's in the works. Some form of this will be in 7.3.
if we are willing to modify libpq to support a white-list, then what you
are suggesting is quite possible.
How would you
Zeugswetter Andreas SB SD writes:
The problem is, that scan.c includes unistd.h before postgres.h
and thus unistd.h defines _LARGE_FILE_API which is not allowed
together with _LARGE_FILES. Do you know an answer ?
Actually, a better idea I just had is to include scan.c at the end of
gram.c
Zeugswetter Andreas SB SD writes:
-brtl , but that does a lot more that we don't want and does not work :-(
I think -bnogc is the switch you want.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the
Bruce Momjian writes:
Well, let's look at the common case. For proper view rules, these would
all return the right values because the UPDATE in the rule would be
returned. Is that what you mean?
I guess that really depends on whether the rules are written to properly
constrain the writes
On Sat, Sep 28, 2002 at 01:08:36PM +0200, Peter Eisentraut wrote:
Jim Mercer writes:
ideally, i'd like to have users-per-database, as opposed to the global
model we have now.
That's in the works. Some form of this will be in 7.3.
cool!
if we are willing to modify libpq to support a
Jim Mercer [EMAIL PROTECTED] wrote:
as it currently stands, virtual hosts can trample all over other
databases,
and with the nature of a single uid for all apache/php/libpq proceses,
they are generally doing it with the same pgsql user.
I haven't followed the whole thread, so perhaps I
On Sat, Sep 28, 2002 at 03:57:27PM +0200, Michael Paesold wrote:
Jim Mercer [EMAIL PROTECTED] wrote:
as it currently stands, virtual hosts can trample all over other
databases,
and with the nature of a single uid for all apache/php/libpq proceses,
they are generally doing it with the same
Shridhar Daithankar wrote:
snip
And what happens when index starts splitting when it grows beyond 1GB in size?
Having an index directory:
i.e. $PGDATA/data/oid/indexes/
(that's the kind of thing you mean isn't it?)
Sounds workable, and sounds better than the present approach.
The reason
Hello,
I did a vacuum from within a function, and it went sig11 on me.
Is it illegal to do that?
The function:
drop function xorder1_cleanup();
create function xorder1_cleanup() RETURNS integer AS '
declare
x record;
c integer;
begin
c:=0;
FOR x IN SELECT order_id,count(*) as cnt FROM
Justin Clift dijo:
Hi,
Ran a benchmark against the database, REINDEX'd the tables, VACUUM FULL
ANALYZE'd, prepared to re-run the benchmark again and guess what?
The indexes were back on the original drive.
Yes, this is expected. Same for CLUSTER. They create a different
filenode and
Neil Conway [EMAIL PROTECTED] writes:
If we used a key that would remain the same between runs of the
postmaster, this should ensure that there isn't a possibility of two
independant sets of backends operating on the same data dir. The most
logical way to do this IMHO would be to just hash
Magnus Naeslund(f) dijo:
Hello,
I did a vacuum from within a function, and it went sig11 on me.
Is it illegal to do that?
Huh... what version is this? In current sources, VACUUM cannot be run
inside a function (it will throw an ERROR). In 7.2[.1] I see there is
no protection against
On Sat, 2002-09-28 at 02:16, Shridhar Daithankar wrote:
On 28 Sep 2002 at 17:08, Justin Clift wrote:
Have moved the indexes to another drive, then created symlinks to them.
Ran a benchmark against the database, REINDEX'd the tables, VACUUM FULL
ANALYZE'd, prepared to re-run the benchmark
I have the beginnings of an idea about improving our interlock logic
for postmaster startup. The existing method is pretty good, but we
have had multiple reports that it can fail during system boot if the
old postmaster wasn't given a chance to shut down cleanly: there's
a fair-sized chance that
Alvaro Herrera [EMAIL PROTECTED] wrote:
Magnus Naeslund(f) dijo:
Hello,
I did a vacuum from within a function, and it went sig11 on me.
Is it illegal to do that?
Huh... what version is this? In current sources, VACUUM cannot be
run inside a function (it will throw an ERROR). In
Alvaro Herrera [EMAIL PROTECTED] writes:
Seems the functionality to detect old versions of the postmaster with
newer psql doesn't work.
What functionality? psql has never had such a test. I think you
are thinking of pg_dump.
regards, tom lane
Justin Clift [EMAIL PROTECTED] writes:
Shridhar Daithankar wrote:
Looks like we should have a subdirectory in database directory which stores
index.
That was my first thought also, but an alternative/additional approach
would be this (not sure if it's workable):
See the tablespaces TODO
Tom Lane dijo:
Alvaro Herrera [EMAIL PROTECTED] writes:
Seems the functionality to detect old versions of the postmaster with
newer psql doesn't work.
What functionality? psql has never had such a test. I think you
are thinking of pg_dump.
No, I was thinking of psql. There was a
As was previously discussed (and now that I'm mostly back from the dead
... damn colds) I've just branched off REL7_3_STABLE ... all future beta's
will be made based off of that branch, so that development may resume on
the main branch ...
So, for those doing commits or anoncvs, remember that
Marc G. Fournier wrote:
As was previously discussed (and now that I'm mostly back from the dead
... damn colds) I've just branched off REL7_3_STABLE ... all future beta's
will be made based off of that branch, so that development may resume on
the main branch ...
What is the attitude
I need to be able to download info from my public library website a
program called Reference USA it will only allow you to download 10 at
a time...I would think there is a way to open this up...any help would
be appreciated.
---(end of
Hi,
So, why not just redirect people to one of the mirrors listed? This
could be done based on IP (yes it is inaccurate but it is close enough
and has the same net effect: pushing people off the main web server) or
it could be done by simply redirecting to a random mirror.
I think it would be
Hi everyone,
In order to clarify things, how about we do a formal vote with specific
details like this:
***
Are you for...
- pg_xlog directory changeable at all, not using symlinks?
Yes/No
- a PGXLOG environment variable to do this?
Yes/No
- a -X command line option to do this?
Hi hackers.
There is ineresting behavior of some select query mentioned in $subj.
In working db this query takes:
real3m10.219s
user0m0.074s
sys 0m0.074s
it's interesting that vacuum or analyze or reinex not helpfull, BUT
if dump this db and create it again (whith another name
I recently downloaded and built Postgresql 7.2.2. In trying to run
the gmake check after the build I get an error indicating that
initdb failed. I turned on the debug option so the text below
contains some of the debug statements output from gmake check. Note
the error at the bottom ERROR:
Hi,
I have a set of points defined in two columns x,y and...
how to convert it to PATH data type using pgplsql ?
Thanks for help
Thomas
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
Is it just me, or is this not very clear?
Could you be more specific on what you need?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of fostered
Sent: Sunday, September 22, 2002 7:04 AM
To: [EMAIL PROTECTED]
Subject: [HACKERS] Will Pay for Help
I need
En Thu, 19 Sep 2002 14:06:05 -0400
Tom Lane [EMAIL PROTECTED] escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane dijo:
One corner case is that I think we currently allow
create table p (f1 int);
create table c (f1 int) inherits(p);
In this case, c.f1.attisinherited
Has there been any thought of providing RAW disk support to bypass the fs?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bruce Momjian
Sent: Thursday, September 26, 2002 3:57 PM
To: Neil Conway
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL
Peter Eisentraut wrote:
Bruce Momjian writes:
Well, let's look at the common case. For proper view rules, these would
all return the right values because the UPDATE in the rule would be
returned. Is that what you mean?
I guess that really depends on whether the rules are written to
Was there a workaround for the errors in time handling for rh7.3 dist?
I get there regression failures:
abstime ... FAILED
tinterval... FAILED
test horology ... FAILED
I remember the discussion about old dates, but not if there was any fix for
Magnus Naeslund(f) wrote:
Was there a workaround for the errors in time handling for rh7.3 dist?
I get there regression failures:
abstime ... FAILED
tinterval... FAILED
test horology ... FAILED
I remember the discussion about old dates, but
Joe Conway [EMAIL PROTECTED] wrote:
Magnus Naeslund(f) wrote:
Was there a workaround for the errors in time handling for rh7.3
dist?
I get there regression failures:
abstime ... FAILED
tinterval... FAILED
test horology ... FAILED
I
I have seen no discussion on whether to go ahead with a 7.2.3 to add
several serious fixes Tom has made to the code in the past few days.
Are we too close to 7.3 for this to be worthwhile? Certainly there will
be people distributing 7.2.X for some time as 7.3 stabilizes.
--
Bruce Momjian
Magnus Naeslund(f) wrote:
Joe Conway [EMAIL PROTECTED] wrote:
Magnus Naeslund(f) wrote:
Was there a workaround for the errors in time handling for rh7.3
dist?
I get there regression failures:
abstime ... FAILED
tinterval... FAILED
test
Bruce Momjian wrote:
I have seen no discussion on whether to go ahead with a 7.2.3 to add
several serious fixes Tom has made to the code in the past few days.
This will allow production sites to run the 7.2 series and also do
VACUUM FULL won't it?
If so, then the idea is already pretty
It was I that originally brought the topic up. I don't really remember
the exact details but I do seem to recall that the author thought it was
a horrid idea. Basically and poorly paraphrased the response was that
everyone should use select version() after they connect and if they
don't know to
On Saturday 28 September 2002 02:36 pm, Bruce Momjian wrote:
I have seen no discussion on whether to go ahead with a 7.2.3 to add
several serious fixes Tom has made to the code in the past few days.
Are we too close to 7.3 for this to be worthwhile? Certainly there will
be people
Bruce Momjian [EMAIL PROTECTED] wrote:
The change was to use localtime() rather than mktime() in the code.
There is no workaround available for 7.2.X, and I don't see that
anyone backpatched it to 7.2 CVS. However, we are considering a
7.2.3 and a backpatch of that fix may be worthwhile.
Justin Clift dijo:
Bruce Momjian wrote:
I have seen no discussion on whether to go ahead with a 7.2.3 to add
several serious fixes Tom has made to the code in the past few days.
This will allow production sites to run the 7.2 series and also do
VACUUM FULL won't it?
If so, then the
Alvaro Herrera [EMAIL PROTECTED] writes:
Memory leaks and such in the PL modules should be backported also.
This is getting out of hand :-(
7.2 is in maintenance status at this point. I'm willing to do backports
for bugs that cause data loss, like this VACUUM/CLOG issue.
Performance problems
Not going to happen ... there are oodles of not big, but useful pieces
of software out there that we could include ... but th epoint of Gborg is
you download the main repository, and then you go to gborg to look for the
add-ons you might like to have ...
On Sun, 29 Sep 2002, Justin Clift
On Sat, 28 Sep 2002 13:41:04 -0400 (EDT), Bruce Momjian
[EMAIL PROTECTED] wrote:
Does anyone else have a common rule that would return incorrect results
using the proposed rules?
CREATE VIEW twotables AS
SELECT ... FROM table1 INNER JOIN table2 ON ... ;
CREATE RULE
Rod Taylor [EMAIL PROTECTED] writes:
Leaving a zero-width table would be best, even if its not so useful. I
don't like rejecting a CASCADE as it kinda defeats the purpose of having
CASCADE.
I did something about this --- as of CVS tip, you can do
regression=# create table foo (f1 int);
Tom Lane dijo:
Alvaro Herrera [EMAIL PROTECTED] writes:
Memory leaks and such in the PL modules should be backported also.
This is getting out of hand :-(
Yes, I agree with you.
Major back-port efforts just aren't going to happen. If they did,
they would significantly impact our
On Sat, 28 Sep 2002, Bruce Momjian wrote:
I have seen no discussion on whether to go ahead with a 7.2.3 to add
several serious fixes Tom has made to the code in the past few days.
Are we too close to 7.3 for this to be worthwhile? Certainly there will
be people distributing 7.2.X for some
Alvaro Herrera [EMAIL PROTECTED] writes:
Maybe there is some way of making the life easier for the upgrader.
Let's see, when you upgrade there are basically two things that change:
a) system catalogs
b) on-disk representation of user data
[much snipped]
Yup. I see nothing wrong with the
On Saturday 28 September 2002 04:14 pm, Tom Lane wrote:
7.2 is in maintenance status at this point. I'm willing to do backports
for bugs that cause data loss, like this VACUUM/CLOG issue.
Performance problems are not on the radar screen at all (especially
not when the putative fixes for them
On Saturday 28 September 2002 04:57 pm, Tom Lane wrote:
7.3 we've changed tuple headers for space-saving reasons, and fixed
some problems with alignment in array data.
Going forward I think we should try to maintain compatibility of on-disk
user data and ensure that pg_upgrade works.
This
Lamar Owen [EMAIL PROTECTED] writes:
This is of course a two-edged sword.
1.) Keeping pg_upgrade working, which depends upon pg_dump working;
... which we have to have anyway, of course ...
2.) Maintaining security fixes for 7.2 for a good period of time to come,
since migration from
Alvaro Herrera wrote:
snip
I agree with Lamar that upgrading is a very difficult process right now.
Requiring huge amounts of disk space and database downtime to do
dump/restore is in some cases too high a price to pay. So maybe the
upgrading process should be observed instead of wasting
Tom Lane wrote:
[ discussion of new startup interlock ]
This is not quite ready for prime time yet, because it's not very
bulletproof against the scenario where two would-be postmasters are
starting concurrently.
A solution to this is to require would-be postmasters to obtain an
exclusive
Tom lane wrote:
True, but I think we'll have to deal with that anyway. Even if the
physical database upgrade were trivial, people are going to find
application compatibility problems due to schemas and other 7.3 changes.
More reasons:
a) learning curve -- I want to use 7.3 and gain some
OK, that is a good example. It would return the sum of the matching
tags. You are suggesting here that it would be better to take the
result of the last matching tag command, right?
---
Manfred Koizar wrote:
On Sat, 28
En Mon, 23 Sep 2002 09:53:08 -0400
Tom Lane [EMAIL PROTECTED] escribió:
You cannot add a column to a table that is inherited by another table
that has a column with the same name:
Yeah, this is an implementation shortcoming in ALTER ADD COLUMN: if it
finds an existing column of the same
Justin Clift wrote:
Alvaro Herrera wrote:
snip
I agree with Lamar that upgrading is a very difficult process right now.
Requiring huge amounts of disk space and database downtime to do
dump/restore is in some cases too high a price to pay. So maybe the
upgrading process should be
Giles Lean [EMAIL PROTECTED] writes:
Is there some reason that file locking is not acceptable? Is there
any platform or filesystem supported for use with PostgreSQL which
doesn't have working exclusive file locking?
How would we know? We have never tried to use such a feature.
For sure I
Alvaro Herrera [EMAIL PROTECTED] writes:
I have this almost ready. The thing I don't have quite clear yet is
what to do with attislocal. IMHO it should not be touched in any case,
but Hannu thinks that for symmetry it should be reset in some cases.
My feeling would be to leave it alone in
Can someone tell me where we are on this; exactly what writability do
we have in 7.3?
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Have we addressed this? I don't think so.
No, it's not done yet. My
Marc Lavergne wrote:
That's an quite a bite to chew given my level of experience with
PostgreSQL internals! However, I will keep it in mind and whatever I do
will be fully abstracted (already is actually) so that it should just a
matter of snapping it into place when 7.4 forks.
On Sat, 2002-09-28 at 16:38, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
Leaving a zero-width table would be best, even if its not so useful. I
don't like rejecting a CASCADE as it kinda defeats the purpose of having
CASCADE.
I did something about this --- as of CVS tip, you
On Saturday 28 September 2002 09:23 pm, Bruce Momjian wrote:
Justin Clift wrote:
Alvaro Herrera wrote:
I agree with Lamar that upgrading is a very difficult process right
As a simple for the user approach, would it be
too-difficult-to-bother-with to add to the postmaster an ability to
Bruce Momjian [EMAIL PROTECTED] writes:
Can someone tell me where we are on this; exactly what writability do
we have in 7.3?
The current code implements what I suggested in that note, viz:
default permissions for new databases are
owner = all rights (ie, create schema and create
Rod Taylor [EMAIL PROTECTED] writes:
I did something about this --- as of CVS tip, you can do
regression=# create table foo (f1 int);
CREATE TABLE
regression=# alter table foo drop column f1;
ALTER TABLE
regression=# select * from foo;
Which of course would dump as 'create table foo
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Can someone tell me where we are on this; exactly what writability do
we have in 7.3?
The current code implements what I suggested in that note, viz:
default permissions for new databases are
owner = all rights (ie, create
regression=# create table foo ();
ERROR: DefineRelation: please inherit from a relation or define an attribute
at least as far as the backend goes.
Found in relcache.c earlier:
AssertArg(natts 0);
Didn't look too hard to see what it protects, because it's more effort
than it's
Rod Taylor [EMAIL PROTECTED] writes:
Found in relcache.c earlier:
AssertArg(natts 0);
Okay, one other place to change ... there are probably more such ...
regards, tom lane
---(end of broadcast)---
TIP 4: Don't
Tom Lane wrote:
Giles Lean [EMAIL PROTECTED] writes:
Is there some reason that file locking is not acceptable? Is there
any platform or filesystem supported for use with PostgreSQL which
doesn't have working exclusive file locking?
How would we know? We have never tried to use such
Is this an open item?
---
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
One problem is, that division already has an inherently inexact
result. Do you intend to rip that out too while at it? (Just
kidding)
Bruce Momjian [EMAIL PROTECTED] writes:
Is this an open item?
Yes. (Fooling with it right now, in fact, in a desultory way ...)
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is this an open item?
Yes. (Fooling with it right now, in fact, in a desultory way ...)
OK, added.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If
Marc, I am still seeing these errors. Would you please fix it?
---
Bruce Momjian wrote:
I am getting errors when doing a checkout, related to Marc's splitting
up the CVS tree into modules:
C
Bruce Momjian dijo:
Justin Clift wrote:
Alvaro Herrera wrote:
As a simple for the user approach, would it be
too-difficult-to-bother-with to add to the postmaster an ability to
start up with the data files from the previous version, for it to
recognise an old data format
Alvaro Herrera [EMAIL PROTECTED] writes:
What would that converter need:
[snip]
I think that should be enough for converting table files. I'd like to
experiment with something like this when I have some free time. Maybe
next year...
It's difficult to say anything convincing on this topic
Marc G. Fournier wrote:
Not going to happen ... there are oodles of not big, but useful pieces
of software out there that we could include ... but th epoint of Gborg is
you download the main repository, and then you go to gborg to look for the
add-ons you might like to have ...
Ok. Wonder
Hi all,
Would it be beneficial for us to extend pg_config to update the
postgresql.conf file?
i.e.
pg_config --sort_mem 16384 --shared_buffers 800
pg_config -d /some/datadir --sort_mem 16384 --shared_buffers 800
etc?
Not sure if it should trigger a restart of postmaster, etc, but the
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Joe Conway wrote:
Tom Lane wrote:
It might
I haven't been following this thread. Can someone answer:
Is TLB Linux-only?
Why use it and non SysV memory?
Is it a lot of code?
---
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
If we
[ I am starting to change subject headings to make things easier for
people.]
I don't think we want a branch for 7.4 yet. We still have lots of open
issues and the branch will require double-patching.
Marc, I know we said branch after beta2 but I think we need another week
or two before we
Bruce Momjian [EMAIL PROTECTED] writes:
Is TLB Linux-only?
Well, the TLB is a feature of the CPU, so no. Many modern processors
support large TLB pages in some fashion.
However, the specific API for using large TLB pages differs between
operating systems. The API I'm planning to
84 matches
Mail list logo
