On Thu, Nov 20, 2003 at 11:45:06AM +0530, Shridhar Daithankar wrote:
Joshua D. Drake wrote:
Is there some way to remove this piece of sh^H^Hlegacy from the
configure script? Does anybody actually use info?
All of GNU.
Additionally it is very good resource when you use Konqueror to
browse
On Thursday 20 November 2003 13:09, David Fetter wrote:
On Thu, Nov 20, 2003 at 11:45:06AM +0530, Shridhar Daithankar wrote:
Joshua D. Drake wrote:
Is there some way to remove this piece of sh^H^Hlegacy from the
configure script? Does anybody actually use info?
All of GNU.
Andreas Pflug kirjutas N, 20.11.2003 kell 01:38:
Second, column type changes needing a nontrivial cast function should be
implemented in a way that preserve attnum. This could be done like this:
- decompile dependent objects, and memorize them for later recreation
- ADD tmpCol, UPDATE
Hannu Krosing wrote:
attnum is used internally to retrieve the data
Oops...
So if an additional column number is invented, it should not be a
logical column number, but a physical storage number for internal data
retrieval. This way, the user interface doesn't change, and all those
tgl wrote:
strk [EMAIL PROTECTED] writes:
Testing postgis support in PG7.4 (2003-11-11)
I've encountered to this problem:
ERROR: could not identify an ordering operator for type geometry
Previous PG versions does not show this problem.
Any hint on what might be missing ?
A
Hi there,
we have a patch for contrib/tsearch2 we'd like to commit for 7.4.1.
Is it ok ?
We added support for compound words using ispell dictionaries.
It's rather important feature for agglutinative languages like
german, norwegian (tested). This work was sponsored by ABC Startsiden
This whole thing is starting to make my head hurt. There has been more
effort spent over this license issue than I would have spent if I hadn't
taken the shortcut of using the FreeBSD code.
I think maybe the simplest thing is for me to prepare a patch that rips
that code out and replaces it
Which is what started the whole discussion.
Dave
On Thu, 2003-11-20 at 04:40, Andreas Pflug wrote:
Hannu Krosing wrote:
attnum is used internally to retrieve the data
Oops...
So if an additional column number is invented, it should not be a
logical column number, but a
Andreas Pflug kirjutas N, 20.11.2003 kell 11:40:
Hannu Krosing wrote:
attnum is used internally to retrieve the data
Oops...
So if an additional column number is invented, it should not be a
logical column number, but a physical storage number for internal data
retrieval.
I think maybe the simplest thing is for me to prepare a patch that rips
that code out and replaces it with a (slightly simpler - less umask
hacking required, I think) piece of code that I will write.
The FreeBSD folks sorted it out for us.
Everyones names should be in the copyright for the
On Wed, 19 Nov 2003 19:07:23 +0100, Andreas Pflug
[EMAIL PROTECTED] wrote:
is there
any DB system out there that allows to reshuffle the column ordering?
Firebird:
ALTER TABLE tname ALTER COLUMN cname POSITION 7;
Servus
Manfred
---(end of
On Wed, 2003-11-19 at 22:50, Bruce Momjian wrote:
Don Sceifers wrote:
My company is fairly new at Postgresql, but we have hit a problem, where
we modify a table using ALTER, and our stored procedures stop working. We
have a grasp as to why this happens, but I was wondering if this v7.4
Don Sceifers wrote:
My company is fairly new at Postgresql, but we have hit a problem,
where
we modify a table using ALTER, and our stored procedures stop working.
We
have a grasp as to why this happens, but I was wondering if this v7.4
upgrade fixes this issue?
Not sure if this
strk [EMAIL PROTECTED] writes:
I've provided a default btree operator class but I'm often
going out of memory when using DISTINCT or UNION clauses.
How can I reduce memory usage in these cases ?
Since passed argument are TOASTED, but I use only a small
initial portion if them to make the
Peter Eisentraut wrote:
Andrew Dunstan writes:
Essentially what I have is something like this pseudocode:
cvs update
Be sure check past branches as well.
check if there really was an update and if not exit
OK.
configure; get config.log
Ideally, you'd try all
Rod Taylor wrote:
I think maybe the simplest thing is for me to prepare a patch that rips
that code out and replaces it with a (slightly simpler - less umask
hacking required, I think) piece of code that I will write.
The FreeBSD folks sorted it out for us.
Everyones names should be in
Oleg Bartunov [EMAIL PROTECTED] writes:
we have a patch for contrib/tsearch2 we'd like to commit for 7.4.1.
Is it ok ?
We added support for compound words using ispell dictionaries.
It's rather important feature for agglutinative languages like
german, norwegian (tested). This work was
Hannu Krosing [EMAIL PROTECTED] writes:
You are just shifting the interface problems to a place needing way more
changes in the backend. There will be some problems either way.
Exactly. I'm considerably more worried about breaking out-of-the-way
places in the backend than I am about what order
Tom Lane writes:
Exactly. I'm considerably more worried about breaking out-of-the-way
places in the backend than I am about what order someone's admin tool
presents the columns in.
Clearly, the effort of adding logical column numbers will consist of
making choices between physical and
Neil Conway [EMAIL PROTECTED] writes:
At present, attnum basically does three things: identifies an column
within a relation, indicates which columns are system columns, and
defines the order of a relation's columns. I'd like to move this last
functionality into a separate pg_attribute column
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Exactly. I'm considerably more worried about breaking out-of-the-way
places in the backend than I am about what order someone's admin tool
presents the columns in.
Clearly, the effort of adding logical column numbers will consist
On Thu, Nov 20, 2003 at 10:39:24AM -0500, Tom Lane wrote:
(c) Do I need to consider inheritance?
Yes. I think it'd be good if things were constrained so that columns
1..n in a parent table always matched columns 1..n in every child,
which is not true now after adding/dropping columns.
Alvaro Herrera Munoz [EMAIL PROTECTED] writes:
On Thu, Nov 20, 2003 at 10:39:24AM -0500, Tom Lane wrote:
(c) Do I need to consider inheritance?
Yes. I think it'd be good if things were constrained so that columns
1..n in a parent table always matched columns 1..n in every child,
which is
Well, that certainly is interesting. Oracle and MS-SQL preserve the
trailing space when concatenating. Does anyone remember the logic for
trimming space with ||?
---
William ZHANG wrote:
Bruce said:
How do other
Rod Taylor wrote:
I think maybe the simplest thing is for me to prepare a patch that rips
that code out and replaces it with a (slightly simpler - less umask
hacking required, I think) piece of code that I will write.
The FreeBSD folks sorted it out for us.
Everyones names should be
On Thu, 20 Nov 2003, Andrew Dunstan wrote:
trollOf course, now that SCO is claiming ownership of BSD code .
/troll
Interesting thread that ... last I read on the FreeBSD lists was
speculation that they would be going after ppl like Cisco (re: TCP/IP
Networking Code) since there really is
Bruce Momjian [EMAIL PROTECTED] writes:
Well, that certainly is interesting. Oracle and MS-SQL preserve the
trailing space when concatenating. Does anyone remember the logic for
trimming space with ||?
trimming space with || is a completely inaccurate description of
what's happening.
7.4
Tom Lane kirjutas N, 20.11.2003 kell 17:18:
Oleg Bartunov [EMAIL PROTECTED] writes:
we have a patch for contrib/tsearch2 we'd like to commit for 7.4.1.
Is it ok ?
We added support for compound words using ispell dictionaries.
It's rather important feature for agglutinative languages
On Thu, 20 Nov 2003 12:40:30 -0500, Tom Lane wrote:
AFAICS the Oracle and SQL Server behaviors are at least as inconsistent
as our own.
If trailing spaces are significant during concatenation,
why aren't they significant to LENGTH()?
Oracle _does_ count the trailing spaces in it's
I just installed a 7.4 on windows/cygwin. I restored a dump but
ran out of disk space during the creating of an index. In psql I
saw the ERROR: could not extend relation .
From that point on it seems to have stopped logging most things.
The ERROR and HINT are not in the log file, it
(I already responded to Bruce, but the response seems to be stuck in some
mailing list, waiting for approval. Trying again:)
On Wed, 19 Nov 2003 14:50:24 -0500, on the BUGS-liste, Bruce Momjian wrote:
Anyway, what did you want it to output? AAA hey? We could do
that, but I assume most
Based on the below wouldn't they also have to go after Microsoft?
Marc G. Fournier wrote:
On Thu, 20 Nov 2003, Andrew Dunstan wrote:
trollOf course, now that SCO is claiming ownership of BSD code .
/troll
Interesting thread that ... last I read on the FreeBSD lists was
speculation
Mark Wong [EMAIL PROTECTED] writes:
I've changed all the numerics to integers and reals, where it was appropriate
to maintain the precision specificed in the TPC-C spec.
...
Looks like I see about an 8% improvement in the metric with this instance. A
definite decrease in user time in the
On Thu, 20 Nov 2003, Joshua D. Drake wrote:
Based on the below wouldn't they also have to go after Microsoft?
Depends ... does MicroSoft use BSD TCP/IP, or did they write their own? I
know that Linux is not using BSD TCP/IP (or, at least, they didn't in
their first 3 incarnations of the stack)
Marc G. Fournier wrote:
On Thu, 20 Nov 2003, Joshua D. Drake wrote:
Based on the below wouldn't they also have to go after Microsoft?
Depends ... does MicroSoft use BSD TCP/IP, or did they write their own? I
know that Linux is not using BSD TCP/IP (or, at least, they didn't in
their
Jan Wieck [EMAIL PROTECTED] writes:
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
The time from release 7.3 to release 7.4 was 355 days, an all-time high.
We really need to shorten that.
I don't see much of a point for a shorter release cycle as long as we
don't get rid of the initdb
--On Thursday, November 20, 2003 16:00:44 -0400 Marc G. Fournier
[EMAIL PROTECTED] wrote:
On Thu, 20 Nov 2003, Joshua D. Drake wrote:
Based on the below wouldn't they also have to go after Microsoft?
Depends ... does MicroSoft use BSD TCP/IP, or did they write their own? I
know that Linux is
Hello,
My understanding is that they use the BSD stack (at least as the
basis) for TCP/IP. Windows that is.
J
Marc G. Fournier wrote:
On Thu, 20 Nov 2003, Joshua D. Drake wrote:
Based on the below wouldn't they also have to go after Microsoft?
Depends ... does MicroSoft use BSD
Kevin Brown [EMAIL PROTECTED] writes:
... That's why the release methodology used by the Linux kernel development
team is a reasonable one.
I do not think we have the manpower to manage multiple active
development branches. The Postgres developer community is a fraction of
the size of the
Larry Rosenman [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
1. Start platform testing on day 1 of beta. Last minute fixes for AIX or
UnixWare are really becoming old jokes.
The only reason we had last minute stuff for UnixWare this time was the
timing of PG's release and the UP3
Josh Berkus wrote:
Shridhar,
However I do not agree with this logic entirely. It pegs the next vacuum
w.r.t current table size which is not always a good thing.
No, I think the logic's fine, it's the numbers which are wrong. We want to
vacuum when updates reach between 5% and 15% of total
Shridhar Daithankar wrote:
Josh Berkus wrote:
Shridhar,
However I do not agree with this logic entirely. It pegs the next
vacuum
w.r.t current table size which is not always a good thing.
Ok, what do you recommend? The point of two separate variables allows
you to specify if you want
On Thursday 20 November 2003 20:00, Matthew T. O'Connor wrote:
Shridhar Daithankar wrote:
I will submit a patch that would account deletes in analyze threshold.
Since you want to delay the analyze, I would calculate analyze count as
deletes are already accounted for in the analyze
On Thursday 20 November 2003 20:29, Shridhar Daithankar wrote:
On Thursday 20 November 2003 20:00, Matthew T. O'Connor wrote:
Shridhar Daithankar wrote:
I will submit a patch that would account deletes in analyze threshold.
Since you want to delay the analyze, I would calculate analyze
Shridhar Daithankar wrote:
On Thursday 20 November 2003 20:00, Matthew T. O'Connor wrote:
Shridhar Daithankar wrote:
I am still wary of inverting vacuum analyze frequency. You think it is
better to set inverted default rather than documenting it?
I think inverting the vacuum and
Matthew,
For small tables, you don't need to vacuum too often. In the testing I
did a small table ~100 rows, didn't really show significant performance
degredation until it had close to 1000 updates.
This is accounted for by using the threshold value. That way small tables
get vacuumed
Shridhar,
I would say -V 0.2-0.4 could be great as well. Fact to emphasize is that
thresholds less than 1 should be used.
Yes, but not thresholds, scale factors of less than 1.0. Thresholds should
still be in the range of 100 to 1000.
I will submit a patch that would account deletes in
Chester Kustarz [EMAIL PROTECTED] writes:
i have some tables which are insert only. i do not want to vacuum them
because there are never any dead tuples in them and the vacuum grows the
indexes.
Those claims cannot both be true. In any case, plain vacuum cannot grow
the indexes --- only a
Kurt Roeckx [EMAIL PROTECTED] writes:
I just installed a 7.4 on windows/cygwin. I restored a dump but
ran out of disk space during the creating of an index. In psql I
saw the ERROR: could not extend relation .
From that point on it seems to have stopped logging most things.
Do you
Troels Arvin [EMAIL PROTECTED] writes:
Why not just change the behaviour back to what it used to be like? I see
no justification for the change:
Well, for one thing, it makes the behavior of comparisons compatible
with the SQL standard. If we have unpleasant side-effects we can work
on those,
Shridhar Daithankar wrote:
Jan Wieck wrote:
I committed the first part of the background writer process. We had a
consensus on attempting to avoid write() calls from regular backends,
but did no come to any conclusions what to do to force the kernel to
actually do some IO.
Consequently, this
Yurgis Baykshtis [EMAIL PROTECTED] writes:
However, we still experience random PG failures on a weekly basis.
PANIC: rename from /data/pg_xlog/00220009 to
/data/pg_xlog/00220012 (initialization of log file 34, segment 18)
failed: No such file or directory
That's curious. Is
Rod Taylor [EMAIL PROTECTED] writes:
On Mon, 2003-11-17 at 20:24, Christopher Kings-Lynne wrote:
BTW, one main consideration is that all the postgres admin apps will now
need to support ORDER BY attlognum for 7.5+.
Yeah... how about maintaining attnum for the logical attribute number
and
Tom Lane [EMAIL PROTECTED] writes:
attpos is a horrid choice of name, because no one will be able to
remember which of attnum and attpos is which. Pick a more
distinct name. Offhand the best thing I can think of is attlognum
or attlogpos.
Actually, I deliberately chose attpos rather than
Yeah, I think the main issue in all this is that for real production
sites, upgrading Postgres across major releases is *painful*. We have
to find a solution to that before it makes sense to speed up the
major-release cycle.
Well, I think one of the simplest is to do a topological sort of objects
Kind people,
Here's something I came up with for finding whether a PostgreSQL 7.4
user is in a group.
Cheers,
D
CREATE OR REPLACE FUNCTION in_group (text, text) RETURNS BOOLEAN AS '
DECLARE
the_user ALIAS FOR $1;
the_group ALIAS FOR $2;
dummy text; -- SELECT INTO dummy because
Neil Conway [EMAIL PROTECTED] writes:
Actually, I deliberately chose attpos rather than attlognum (which is
what some people had been calling this feature earlier). My reasoning
was that the logical number is really a nonsensical idea: we just
invented it on the spot.
True ...
In contrast,
I don't have a better choice of name offhand, but if we spend 1% of the
time already spent arguing about these issues on finding a better name,
I'm sure we can think of one ;-)
virtual (attvirtnum)
external (attextnum)
atttisoywnum - attribute this is the one you want number
Yurgis Baykshtis [EMAIL PROTECTED] writes:
The most interesting thing is that rename failure is always followed by
IpcMemoryCreate and vice-versa, IpcMemoryCreate always comes after the
rename error.
That is not interesting ... it's exactly what I'd expect for the panic
recovery sequence
I noticed the following code in src/backend/rewrite/rewriteDefine.c,
circa line 390:
/*
* Are we converting a relation to a view?
*
* If so, check that the relation is empty because the storage
* for the relation
Rod Taylor [EMAIL PROTECTED] writes:
Personally, I think the best way is simply to make a post on -hackers
with a description of what you want to accomplish with a call for
estimates and proposals. ...
I say a description of what you want to accomplish because certain
features are not as
Tom Lane wrote:
Chester Kustarz [EMAIL PROTECTED] writes:
vacuum is to reclaim dead tuples. this means it depends on update and
delete. analyze depends on data values/distribution. this means it depends on
insert, update, and delete. thus the dependencies are slightly different
between the 2
Josh Berkus wrote:
Matthew,
For small tables, you don't need to vacuum too often. In the testing I
did a small table ~100 rows, didn't really show significant performance
degredation until it had close to 1000 updates.
This is accounted for by using the threshold value. That way
Matthew,
110% of a 1.1 million row table is updated, though, that vaccuum will
take an hour or more.
True, but I think it would be one hour once, rather than 30 minutes 4
times.
Well, generally it would be about 6-8 times at 2-4 minutes each.
This is one of the things I had hoped to add
64 matches
Mail list logo
