For those of you who have missed it, here
http://www.google.com/search?q=cache:web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf+clark+end+to+endhl=en
is the paper some of us mention, END-TO-END ARGUMENTS IN SYSTEM DESIGN
by Saltzer, Reed, and Clark.
The abstract is:
This paper
Hello Kids, i'am new here, excuseme by my english, but i'm amateur
i need to know how i can increase speed on the query (any query) without use
vacumm??
too, which is the procedure for made the trigger always update the table
pg_statistic when i do any transaction.
by the way, too need use
Hello,
I have spend some thinking about implementation of DOMAIN capability.
Here are my ideas.
What is a domain? It is an alias for a type with size, constraints and
default values. It is like one column of a table. And this is the main
idea of my "implementation". It should be possible to
I think the restore process could be made more error proof if the following
additions could be made:
pg_dump, (maybe started with a special flag) if run with superuser rights
should not issue
\connect - username
create table foo (...
copy foo from ...
to create tables, but use this syntax:
pgsql-hackers is for folks who are developing pgsql...
Consider posting to -general which is for people using pgsql..
jacky_shu [EMAIL PROTECTED] wrote in message
9e0q9v$q0p$[EMAIL PROTECTED]">news:9e0q9v$q0p$[EMAIL PROTECTED]...
Hello everyone:
I am a novice in postgreSQL.So i want to get
=?iso-8859-2?Q?Hor=E1k_Daniel?= [EMAIL PROTECTED] writes:
When a new domain is created it will:
- put a record into pg_type with typnam = domain name, new code for
typtype = 'd' and typrelid = oid of a new record in pg_class (next line)
- put a record into pg_class to create a fictional table
On Thu, May 17, 2001 at 06:04:54PM +0800, Lincoln Yeoh wrote:
At 12:24 AM 17-05-2001 -0700, Nathan Myers wrote:
For those of you who have missed it, here
http://www.google.com/search?q=cache:web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf+clark+end+to+endhl=en
is the paper
I have been thinking about the problem of VACUUM and how we might fix it
for 7.2. Vadim has suggested that we should attack this by implementing
an overwriting storage manager and transaction UNDO, but I'm not totally
comfortable with that approach: it seems to me that it's an awfully large
Hello,
I've noticed that all custom operators or inet type (such as , =, etc)
cannot use an index, even though it is possible to define such an
operation on an index, for ex:
X Y can be translated to X = network(Y) X = broadcast(Y) (or so)
According to docs, postgres has hard-coded the ops
Heck ya...
I wonder if cache failures should be what drives the vacuum daemon to
vacuum a table? Sort of like, Hey, someone is asking for free pages
for that table. Let's go find some! That may work really well.
Another advantage of centralization is that we can record update/delete
Matthew T. O'Connor [EMAIL PROTECTED] writes:
Another quick thought for handling FSM contention problems. A backend could
give up waiting for access to the FSM after a short period of time, and just
append it's data to the end of the file the same way it's done now. Dunno
if that is
At 19:05 17/05/01 -0400, Tom Lane wrote:
But having said that, there's no reason to remove the existing VACUUM
code: we can keep it around for situations where you need to crunch a
table as much as possible and you can afford to lock the table while
you do it.
It would be great if this was
mlw [EMAIL PROTECTED] writes:
My only suggestion would be to store some information in the statistics about
whether or not, and how bad, a table needs to be vacuumed.
I was toying with the notion of using the FSM to derive that info,
somewhat indirectly to be sure (since what the FSM could
On Thu, 17 May 2001, Lamar Owen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 16 May 2001 19:05, The Hermit Hacker wrote:
On Wed, 16 May 2001, Lamar Owen wrote:
I am loathe to even bring this up, but with two messages today about it,
I am going to be short and
Peter Eisentraut - PostgreSQL [EMAIL PROTECTED] writes:
Add dynamic_library_path parameter and automatic appending of shared
library extension.
Looks good. One tiny nit: I think that DLSUFFIX should be appended if
the given basename doesn't contain any '.', rather than first
Peter Eisentraut [EMAIL PROTECTED] writes:
1. createlang should no longer insert libdir or dlsuffix into the
function declarations it makes
How do we handle the case where the user changed the path? Do we say,
$libdir needs to be in the path or you're on your own?
Seems OK to me, but ...
Mike Mascari [EMAIL PROTECTED] writes:
Very neat. You mention that the truncation of both heap and index
relations is not necessarily mandatory. Under what conditions would
either of them be truncated?
In the proposal as given, a heap file would be truncated if (a) it
has at least one
Bruce Momjian [EMAIL PROTECTED] writes:
The only question I have is about the Free Space Map. It would seem
better to me if we could get this map closer to the table itself, rather
than having every table of every database mixed into the same shared
memory area. I can just see random table
18 matches
Mail list logo
