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
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 a
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 i
"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 sequen
> 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
---
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 co
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 PERFO
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
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 sma
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
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
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
"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 curio
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
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 thos
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 yo
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
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 L
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 TCP/I
--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
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
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 firs
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)
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 t
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:
Of course, now that SCO is claiming ownership of BSD code .
Interesting thread that ... last I read on the FreeBSD lists was
speculation that they wou
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
(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 mo
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 stop
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 LENGTH
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 la
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 a
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.
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 vacuu
On Thu, 20 Nov 2003, Andrew Dunstan wrote:
> Of course, now that SCO is claiming ownership of BSD code .
>
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 nobody else
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 s
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 d
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 ana
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,
>>
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 colum
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
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 co
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 logi
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 or
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
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 the
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 an
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 thr
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 possible
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
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 vacu
> > 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 sur
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.
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 broadcast)-
> 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 th
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
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 numbe
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 wit
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
(www.startsi
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 miss
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
"SEL
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 tmp
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
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 t
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
64 matches
Mail list logo
