Hi,
7.4beta4 is still mentioned in INSTALL.
Tommi
Am Mittwoch, 22. Oktober 2003 16:21 schrieb Marc G. Fournier:
'K, I packaged it up last night so that the ftp mirrors could get up to
date on it ... I'm going to put out an announce to -general and -announce
on this later this evening, but
Hi,
I installed 7.4beta5, created a data-dir and tried to start postgresql with
pg_ctl without initdb. As expected, this will fail. But pg_ctl tells me
postmaster successfully started, after a fatal error, which looks very
confusing. When I use -l for specifying a logfile, I don't even see the
On Wednesday 22 October 2003 20:12, scott.marlowe wrote:
On Wed, 22 Oct 2003, Tom Lane wrote:
It would probably be a good idea to allow the function's search path to
be explicitly specified as a clause of CREATE FUNCTION (otherwise it
will be a headache for pg_dump). So we could allow both
On Wednesday 22 October 2003 07:37, Neil Conway wrote:
The second audience is the people who are really interested in exactly
what has changed between the new release of PostgreSQL and the previous
release series. It is important that we make it easy for an admin
planning a PostgreSQL
On Friday 24 October 2003 00:01, Christoph Haller wrote:
A pg_compat_chk utility sounds great.
No idea, if this is practical, but it's desirable - at least to me.
Well, I'm confident the first 90% is practical just by running some regexps
against a pg_dumped schema. It doesn't need to
Rod Taylor wrote:
On Tue, 2003-10-21 at 21:24, Christopher Kings-Lynne wrote:
There is always the biggest evil of all... Putting SHOW / DESCRIBE /
HELP commands into the backend itself. I'm sure the pgAdmin group likes
that idea (they're probably tired of maintaining 4 different versions of
On Wed, 22 Oct 2003, Christopher Browne wrote:
No, tables wouldn't be the right way to do it.
But it's going to be troubled, in any case, because of the
every-popular mixtures of:
a) Often weird declarations of what character sets are in use;
I gotta admit that I haven't spend too much
-Original Message-
From: Bruce Momjian
...
The big question is whether the current release notes hit he right
balanced. Do they for you?
The last time I read the notes was when we upgraded to 7.3.4.
I'll pick up couple entries from Release Notes and the HISTORY file
(which we always
On Thu, 23 Oct 2003, Christopher Kings-Lynne wrote:
4. Extend the contrib/ltree gist-based tree indexing scheme to work on
xml and hence the operations in no.3 above are really fast...
but then, the plain xml data is still stored in a database colum, if I
understand correctly?
--
Gregor
On Wed, 22 Oct 2003, Josh Berkus wrote:
Reinvent the wheel? Well, yes.
The first thing ... the VERY first thing, abosolutely ... that you need to do
is invent a theory of XML databases.
Well, I have. It doen't cover all parts in detail yet, because I've
started with a simple IO layer (simple
Storing the XML text has problems - you have to parse it every time you
want something - that has to cause a huge performance hit.
I use XML a lot for all sorts of purposes, but it is appropriate for
data transfer rather than data storage, IMNSHO.
cheers
andrew
Christopher Kings-Lynne wrote:
On Thu, 23 Oct 2003, Andrew Dunstan wrote:
Storing the XML text has problems - you have to parse it every time you
want something - that has to cause a huge performance hit.
You couldn't have said better what I meant.
I store the xml already parsed. You can navigate right along. To the
parent,
Nay... I would expect a PostgreSQL specific information_schema to get
just as much mucking around as the system tables, which means you are
still maintaining a set of queries per release.
The problem about information_schema is that it's restricted to show
objects of the owner only.
4. Extend the contrib/ltree gist-based tree indexing scheme to work on
xml and hence the operations in no.3 above are really fast...
but then, the plain xml data is still stored in a database colum, if I
understand correctly?
Yep - which to me seems to be the most useful way to store it :)
Chris
*nod* I have tried this several times - it just doesn't work well,
because the maps are too different.
You could do something like this:
. a table for each element type, fields being the attributes, plus
the node id.
. a table to tie everything together (parent_id, child_id,
Tommi Maekitalo [EMAIL PROTECTED] writes:
I installed 7.4beta5, created a data-dir and tried to start postgresql with
pg_ctl without initdb. As expected, this will fail. But pg_ctl tells me
postmaster successfully started, after a fatal error, which looks very
confusing. When I use -l for
On Thu, 23 Oct 2003, Christopher Kings-Lynne wrote:
You couldn't have said better what I meant.
I store the xml already parsed. You can navigate right along. To the
parent, the previous, the next elemnt or the first or last child.
Which is the whole point of indexing it...
not quite.
Gregor,
Well, I have. It doen't cover all parts in detail yet, because I've
started with a simple IO layer (simple page locking, no concurrent
transactions) and worked on the page layout and parsing algorithms from
there on. Querying on that format will follow thereafter. And concurrency
If you don't use -w, then pg_ctl doesn't wait around to see whether the
postmaster started or not. It'd probably be a good idea for it to issue
a less positive message in this case, maybe only postmaster launched.
I also wonder why -w isn't the default.
I've also noticed that on our production
Tom Lane wrote:
Tommi Maekitalo [EMAIL PROTECTED] writes:
I installed 7.4beta5, created a data-dir and tried to start postgresql with
pg_ctl without initdb. As expected, this will fail. But pg_ctl tells me
postmaster successfully started, after a fatal error, which looks very
confusing.
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I've also noticed that on our production 7.3.4 server logging to syslog,
that if I change the postgresql.conf to enable log_statement, and then
do pg_ctl reload, it works, but then when I disable it again, pg_ctl
reload does not cause
On Thu, 23 Oct 2003, Josh Berkus wrote:
Um, I/O and Page layout are not theory. They are implementation issues.
yes or no, depending on your point of view.
Theory would answer things like What are the mathematical operations I can
use to define compliance or non-compliance with the DTD for a
By disable do you mean turn off, or comment out again? The latter
is not going to affect the state of the postmaster ...
The latter...why won't it affect the postmaster state?
Chris
---(end of broadcast)---
TIP 6: Have you searched our list
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
By disable do you mean turn off, or comment out again? The latter
is not going to affect the state of the postmaster ...
The latter...why won't it affect the postmaster state?
Because it's a *comment*.
regards, tom
The latter...why won't it affect the postmaster state?
Because it's a *comment*.
Shouldn't it revert to the default value?
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
Michael Brusser wrote:
-Original Message-
From: Bruce Momjian
...
The big question is whether the current release notes hit he right
balanced. Do they for you?
The last time I read the notes was when we upgraded to 7.3.4.
I'll pick up couple entries from Release Notes and
Tommi Maekitalo wrote:
Hi,
7.4beta4 is still mentioned in INSTALL.
Oh, I didn't realize the beta number was in the install. I just updated
it, and we will have the right numbers in the for final.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
Andrew Dunstan wrote:
Tom Lane wrote:
Tommi Maekitalo [EMAIL PROTECTED] writes:
I installed 7.4beta5, created a data-dir and tried to start postgresql with
pg_ctl without initdb. As expected, this will fail. But pg_ctl tells me
postmaster successfully started, after a fatal error,
Tom Lane wrote:
Tommi Maekitalo [EMAIL PROTECTED] writes:
I installed 7.4beta5, created a data-dir and tried to start postgresql with
pg_ctl without initdb. As expected, this will fail. But pg_ctl tells me
postmaster successfully started, after a fatal error, which looks very
Bruce Momjian wrote:
OK, I updated the Win32 web page to mention we need a C version of
pg_ctl. I don't think we will need pg_config once we have initdb in C,
and I don't think it is worth doing initlocation because we need
tablespaces.
I will put it on my todo list (should be simpler than
Bob Badour [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
All physical structures will bias performance for some operations and
against others.
This strikes me as a succinct statement of the value of
data independence. One has the option (but not the
requirement) to adjust the
Lauri Pietarinen [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Anthony W. Youngman wrote:
In article [EMAIL PROTECTED], Lauri Pietarinen
[EMAIL PROTECTED] writes
Anthony W. Youngman wrote:
Fine. But MV *doesn't* *need* much of a cache. Let's assume both SQL
and
MV
Anthony W. Youngman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
As soon as a requirement for a database specifies extraction of the
maximum power from the box,
I don't for a second believe that this is your only requirement,
or that this is even an actual requirement. If it
Anthony W. Youngman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Just like the academics were
brainwashed into thinking that microkernels were the be-all and end-all
- until Linus showed them by practical example that they were all idiots
The academics (presumably you mean
Anthony W. Youngman wrote:
In article [EMAIL PROTECTED], Lauri Pietarinen
[EMAIL PROTECTED] writes
Anthony W. Youngman wrote:
Fine. But MV *doesn't* *need* much of a cache. Let's assume both SQL and
MV have the same amount of RAM to cache in - i.e. *not* *much*. I did
say the spec said
Marshall Spight [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Bob Badour [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
All physical structures will bias performance for some operations and
against others.
This strikes me as a succinct statement of the value of
In article [EMAIL PROTECTED], Lauri Pietarinen
[EMAIL PROTECTED] writes
Anthony W. Youngman wrote:
Fine. But MV *doesn't* *need* much of a cache. Let's assume both SQL and
MV have the same amount of RAM to cache in - i.e. *not* *much*. I did
say the spec said extract maximum performance from the
Hi!
I'm doing a select (from an OACS page or from psql) and I get:
ERROR: Failed to create temporary file pgsql_tmp/pgsql_tmp27212.775
The same select work ok a different database (which is on a different
machine)
the select is :
select a.attribute_id, a.pretty_name,
Sounds like your drives are full.
On Thu, 23 Oct 2003, Yuval Lieberman wrote:
Hi!
I'm doing a select (from an OACS page or from psql) and I get:
ERROR: Failed to create temporary file pgsql_tmp/pgsql_tmp27212.775
The same select work ok a different database (which is on a different
Marshall Spight kirjutas N, 23.10.2003 kell 11:01:
Anthony W. Youngman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Just like the academics were
brainwashed into thinking that microkernels were the be-all and end-all
- until Linus showed them by practical example that they were
I'm seeing on the log file:
LOG: duration: 0.024814 select now();
Am I wrong or we agree to have:
LOG: duration: 24.81 ms select now();
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Gaetano Mendola wrote:
I'm seeing on the log file:
LOG: duration: 0.024814 select now();
Am I wrong or we agree to have:
LOG: duration: 24.81 ms select now();
I think you are pointing to the wrong version --- I see:
LOG: duration: 0.998 ms statement: select 1;
--
Bruce
Bruce Momjian wrote:
I think you are pointing to the wrong version --- I see:
LOG: duration: 0.998 ms statement: select 1;
I'm a dummy, I forgot to do gmake install
after have compiled the last beta :-(
yes you're right.
Regards
Gaetano Mendola
---(end of
Hello
This is my first time to
post.
I
have several questions.
Currently,
there is Postgresql for ia64.
I
was wondering, previous version was optimized for ia64 or just
converted.
Now
I am looking for some way to optimize postgresql especially for ia64
machine.
(thinking
about
Satoshi, can you get this ready for inclusion in 7.5? We need a formal
proposal of how it will work from the user's perspective (new
commands?), and how it will internally work. It seem Heikki Linnakangas
has also started working on this and perhaps he can help.
Ideally, we should have this
Bruce,
Ok, I will write my proposal.
BTW, my 2PC work is now suspended because of my master thesis.
My master thesis will (must) be finished in next few months.
To finish 2PC work, I feel 2 or 3 months are needed after that.
Bruce Momjian wrote:
Satoshi, can you get this ready for inclusion
Bruce Momjian [EMAIL PROTECTED] writes:
Michael Brusser wrote:
Optimizer improvements
= this tells me nothing. I suppose this could be a minor internal code
tweak, which does not affect me. On the other hand this could be a major
breakthrough, so now I can run some stupid query which
I am not sure we should add something to the SET CONSTRAINT page on
this. Our current behavior is clearly a bug, and for that reason
belongs more on the TODO list, where it already is:
* Have AFTER triggers execute after the appropriate SQL statement in a
function, not
Satoshi Nagayasu wrote:
Bruce,
Ok, I will write my proposal.
BTW, my 2PC work is now suspended because of my master thesis.
My master thesis will (must) be finished in next few months.
To finish 2PC work, I feel 2 or 3 months are needed after that.
Oh, OK, that is helpful. Perhaps
Greg Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Michael Brusser wrote:
Optimizer improvements
= this tells me nothing. I suppose this could be a minor internal code
tweak, which does not affect me. On the other hand this could be a major
breakthrough, so now I can run
I can confirm this bug in CVS.
---
Rod Taylor wrote:
-- Start of PGP signed section.
May have posted this earlier...
It would seem that caching the plans for foreign keys has some unwanted
side effects.
test=#
On Fri, 24 Oct 2003, Bruce Momjian wrote:
I am not sure we should add something to the SET CONSTRAINT page on
this. Our current behavior is clearly a bug, and for that reason
belongs more on the TODO list, where it already is:
Had it been on the SET CONSTRAINT page, it would have saved me
hi:in allpath.c ,the
set_plan_rel_pathlist() function has a parameter of RangeTblEntry type.what
does we use this varaible to do ?i doesn't see any code in this function
using it .In optimizer module, it look like that we can get
mostinformation from Query . Is it right ?so , what time use
Curt Sampson wrote:
On Fri, 24 Oct 2003, Bruce Momjian wrote:
I am not sure we should add something to the SET CONSTRAINT page on
this. Our current behavior is clearly a bug, and for that reason
belongs more on the TODO list, where it already is:
Had it been on the SET CONSTRAINT
54 matches
Mail list logo
