On 28 Sep 2002 at 12:18, Tom Lane wrote:
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
On 29 Sep 2002 at 0:43, Justin Clift wrote:
Shridhar Daithankar wrote:
The reason that I was thinking of having a different path per index
would be for high volume situations like this:
/dev/dsk1 : /pgdata - data here
/dev/dsk2 : /pgindexes1 - some indexes here
/dev/dsk3 : /pgindexes2 -
Am Samstag, 28. September 2002 10:17 schrieb Shridhar Daithankar:
(snip)
I have to disagree.. Completely.. This is like turning PG-Metadata into
registry...
And what happens when index starts splitting when it grows beyond 1GB in
size?
Putting indexes into a separate subdirectoy and
On Sun, 2002-09-29 at 07:19, Lamar Owen wrote:
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
On Sun, 2002-09-29 at 09:47, Tom Lane wrote:
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...
Hi, all
Does 7.3 support SETOF RECORD in plpgsql ?
As far as I test it, a function using it in plpgsql always seems to return
no row. On the other hand, a sql function returns correct rows.
If 7.3 doesn't support it in plpgsql, I would think plpgsql needs to raise
an error rather than return
CREATE OR REPLACE FUNCTION myfunc(integer) RETURNS SETOF record AS '
DECLARE
rec record;
BEGIN
FOR rec IN SELECT * FROM test WHERE a = $1 LOOP
RAISE NOTICE ''a = %, b = %'',rec.a, rec.b;
RETURN NEXT rec;
END LOOP;
RETURN null;
END;
Tom Lane kirjutas P, 29.09.2002 kell 04:00:
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
Jim Mercer writes:
the reasoning for this is that postmaster has no ability to differentiate
between incoming sessions, and as such, storing the list in the server makes
no sense, the server won't know how to apply the list.
Right, but libpq also has no concept of what you call incoming
Justin Clift writes:
Would it be beneficial for us to extend pg_config to update the
postgresql.conf file?
That has nothing to do with pg_config's functions.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe
Peter Eisentraut wrote:
Justin Clift writes:
Would it be beneficial for us to extend pg_config to update the
postgresql.conf file?
That has nothing to do with pg_config's functions.
At present, sure. Was thinking a tool for command line changes of
postgresql.conf parameters would be
Neil Conway wrote:
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
Hannu Krosing [EMAIL PROTECTED] writes:
The initial Postgres design had a notion of StorageManager's, which
should make this very easy indeed, if it had been kept working .
But the storage manager interface was never built to hide issues like
tuple representation --- storage managers just deal
Hannu Krosing [EMAIL PROTECTED] writes:
I'd propose that ADD ONLY would pull topmost attislocal up (reset it
from the (grand)child) whereas plain ADD would leave attislocal alone.
ADD ONLY? There is no such animal as ADD ONLY, and cannot be because
it implies making a parent inconsistent with
Justin Clift [EMAIL PROTECTED] writes:
Would it be beneficial for us to extend pg_config to update the
postgresql.conf file?
This seems far outside pg_config's charter. It is a simple
information reporter that can be run by anybody. Making it able
to mess with (or even look at)
Bruce Momjian [EMAIL PROTECTED] writes:
OK, personally, I would like to see an actual speedup of PostgreSQL
queries before I would apply such a OS-specific, version-specific
patch.
Don't be silly. A performance improvement is a performance
improvement. According to your logic, using
Bruce Momjian [EMAIL PROTECTED] writes:
Marc, I know we said branch after beta2 but I think we need another week
or two before we can start using that branch effectively. Even if we
started using it, like adding PITR, the code would drift so much that
the double-patching would start to fail
Neil Conway [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, personally, I would like to see an actual speedup of PostgreSQL
queries before I would apply such a OS-specific, version-specific
patch.
Don't be silly. A performance improvement is a performance
improvement.
On Sun, 29 Sep 2002 13:42:43 +0200
Grant Finnemore [EMAIL PROTECTED] wrote:
Note the use of the RETURN NEXT rec line in the body
of the for loop, and also the RETURN null at the end.
It is also possible to create typed returns, so in this
case, in the declare body, the following would be
Tom Lane wrote:
snip
Marc previously proposed releasing beta3 in about a week --- will that
be a good time to open HEAD for 7.4 work, or will we need to delay still
longer? (I'm not sure yet, myself.)
Perhaps it's too early to be able to effectively say when a
real+effective branch is likely
On Sun, 29 Sep 2002, Tom Lane wrote:
Justin Clift [EMAIL PROTECTED] writes:
Would it be beneficial for us to extend pg_config to update the
postgresql.conf file?
This seems far outside pg_config's charter. It is a simple
information reporter that can be run by anybody. Making it able
On Sun, 29 Sep 2002, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
I'd propose that ADD ONLY would pull topmost attislocal up (reset it
from the (grand)child) whereas plain ADD would leave attislocal alone.
ADD ONLY? There is no such animal as ADD ONLY, and cannot be because
On Fri, Sep 27, 2002 at 09:53:02AM -0700, Joe Conway wrote:
It is in 7.3.
If the return tuple definition is fixed:
instead of:
exec sp_myproc()
go
do
select * from sp_myproc();
That's a great feature to have.
If the return tuple definition is *not* fixed:
do
select
Alvaro Herrera wrote:
Obviously he wants a tool that allows setting parameters from a shell
script or something for use within pg_autotune. I don't see why it is
bad to have a tool to do this; if someone can use it (and modify
postgresql.conf) obviously he has permission to read (and write)
Joe Conway wrote:
Alvaro Herrera wrote:
Obviously he wants a tool that allows setting parameters from a shell
script or something for use within pg_autotune. I don't see why it is
bad to have a tool to do this; if someone can use it (and modify
postgresql.conf) obviously he has
On Sun, 2002-09-29 at 19:57, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
I'd propose that ADD ONLY would pull topmost attislocal up (reset it
from the (grand)child) whereas plain ADD would leave attislocal alone.
ADD ONLY? There is no such animal as ADD ONLY, and cannot be
-Original Message-
From: CoL [mailto:[EMAIL PROTECTED]]
Sent: 24 September 2002 13:23
To: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Web site
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
On Sun, 2002-09-29 at 19:28, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
The initial Postgres design had a notion of StorageManager's, which
should make this very easy indeed, if it had been kept working .
But the storage manager interface was never built to hide issues like
On 29 Sep 2002, Hannu Krosing wrote:
On Sun, 2002-09-29 at 19:57, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
I'd propose that ADD ONLY would pull topmost attislocal up (reset it
from the (grand)child) whereas plain ADD would leave attislocal alone.
ADD ONLY? There is
Hi,
Now that the ODBC driver has moved from the main distro to
http://gborg.postgresql.org/project/psqlodbc/, we can no longer use the
main build system under *nix.
Can someone who knows make better than I (which is probably the vast
majority of you!) knock up a makefile so the driver will
Peter Eisentraut wrote:
Bruce Momjian writes:
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.
Merge the changes on the 7.3 branch into the 7.4 branch after 7.3 is
released.
Yes, there is something to be said
Peter, the author is questioning why his Makefile changes were wrong.
Would you elaborate?
---
pgman wrote:
Done.
---
Peter Eisentraut
I read a good article about the problem Intel is having with the 64-bit
Itanium. I think there are some good leasons in the article:
http://www.nytimes.com/2002/09/29/technology/circuits/29CHIP.html
There is also a Slashdot discussion about the article:
can you create a project on gborg under 'server modules' for this?
On Sun, 29 Sep 2002, Bruce Momjian wrote:
Marc, I am still seeing these errors. Would you please fix it?
---
Bruce Momjian wrote:
I am getting
Neil,
I agree with Bruce and Tom. AFAIK and in my experience I don't think it
will be a significantly measurable increase. Not only that, but the
portability issue itself tends to make it less desireable. I recently
ported SAP DB and the coinciding DevTools over to OpenBSD and learned again
Jonah H. Harris [EMAIL PROTECTED] writes:
I agree with Bruce and Tom.
AFAIK Bruce and Tom (and myself) agree that this is a good idea,
provided it makes a noticeable performance difference (and if it
doesn't, it's not worth applying).
AFAIK and in my experience I don't think it will be a
Alvaro Herrera [EMAIL PROTECTED] writes:
I implemented ADD ONLY as a way to add the column only in the parent
(all children should already have to column, errors if at least one
doesn't or is different atttype), while ADD adds the column to
children that don't have it and merges where already
Marc G. Fournier wrote:
can you create a project on gborg under 'server modules' for this?
Uh, I don't see the logic in moving earthdistance out of /contrib. It
uses /cube, which is in contrib. I didn't think we were moving loadable
modules out to gborg yet, and I didn't think we were doing
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian writes:
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.
Merge the changes on the 7.3 branch into the 7.4 branch after 7.3 is
released.
Why is that better
39 matches
Mail list logo
