I'm wondering how useful it is to store explicit representations of the
system attributes in pg_attribute. We could very easily hard-wire those
things instead, which would make for a large reduction in the number of
entries in pg_attribute. (In the current regression database nearly
half of the
Marc,
Below is a message I just received and I'm wondering what's a problem
of such delay ? 5 days is too much :)
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical
One point that I no longer recall the reasoning behind is that xlog.c
doesn't think O_SYNC is a preferable default over fsync.
For larger (8k) transactions O_SYNC|O_DIRECT is only good with the recent
pending patch to group WAL writes together. The fsync method gives the OS a
chance
On win32 (which started this discussion, fsync will sync the
directory
entry as well, which will lead to *at least* two seeks on the disk.
Writing two blocks after each other to an O_SYNC opened file should
give
exactly two seeks.
I think you are making the following not maintainable
On Mon, 21 Feb 2005, Oleg Bartunov wrote:
Marc,
Below is a message I just received and I'm wondering what's a problem
of such delay ? 5 days is too much :)
It was posted by someone not subscribed to the mailing list, and had to be
manually approved by the moderator (me) before it would go
On Feb 20, 2005, at 11:02 AM, Stephan Szabo wrote:
My last company's experience with Oracle support still leaves me
questioning that claim. They basically got don't do that then or
move to
the newest major revision when they had a construct which caused the
server to stop responding.
For the
On Mon, 21 Feb 2005, Marc G. Fournier wrote:
On Mon, 21 Feb 2005, Oleg Bartunov wrote:
Marc,
Below is a message I just received and I'm wondering what's a problem
of such delay ? 5 days is too much :)
It was posted by someone not subscribed to the mailing list, and had to be
manually approved by
Sounds a bit like multi-dimensional clustering ...
http://www.research.ibm.com/mdc/
After the ARC experience though ...
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Doug McNaught wrote:
John DeSoi [EMAIL PROTECTED] writes:
I'm communicating with psql via a pipe stream. This works pretty well,
but one problem I have is trying to cancel an operation. If I send a
sigint, psql dies. In looking at the source I gather this is because
it assumes I'm in
Jeff wrote:
On Feb 20, 2005, at 11:02 AM, Stephan Szabo wrote:
My last company's experience with Oracle support still leaves me
questioning that claim. They basically got don't do that then or
move to
the newest major revision when they had a construct which caused the
server to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It occurs to me that without the explicit entries, we could stop
considering the system names to be reserved column names --- that is,
we could allow users to create ordinary columns by these names.
(The procedure for looking up a column name
I'm communicating with psql via a pipe stream. This works
pretty well,
but one problem I have is trying to cancel an operation.
If I send a
sigint, psql dies. In looking at the source I gather this
is because
it assumes I'm in non-interactive mode (pset.notty is true). I was
wondering
On Feb 21, 2005, at 3:00 PM, Magnus Hagander wrote:
There is no way so signal *psql*, as in the client side process. The
signal emulation only runs in the server.
You can do the same thing in the server using pg_ctl kill, but that
won't work on client processes.
Thanks to everyone for the feedback
Hi Magnus,
On Feb 21, 2005, at 3:00 PM, Magnus Hagander wrote:
There is no way so signal *psql*, as in the client side process. The
signal emulation only runs in the server.
But is there some equivalent of pressing ctrl-C to make psql stop what
it is doing? For example, through the pipe stream I
John DeSoi wrote:
Hi Magnus,
On Feb 21, 2005, at 3:00 PM, Magnus Hagander wrote:
There is no way so signal *psql*, as in the client side process. The
signal emulation only runs in the server.
But is there some equivalent of pressing ctrl-C to make psql stop what
it is doing? For
There is no way so signal *psql*, as in the client side process. The
signal emulation only runs in the server.
But is there some equivalent of pressing ctrl-C to make psql stop what
it is doing? For example, through the pipe stream I may execute a \i
command and the user wants to stop before
My understanding from this is:
If we have a buffer cache hit ratio of 93%, then we should expect:
- 93% of buffer requests to require only shared BufMappingLocks
- 7% of buffer requests would require an exclusive BufFreelistLock then
an exclusive BufMappingLock.
That seems like an improvement
On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.
Might we set a rough date for Beta freeze for 8.1 then?
September 30th 2005 ?
I see
Simon Riggs [EMAIL PROTECTED] writes:
[I'm assuming that there are no system-wide locks held across I/Os, that
bit seems a bit unclear from the description]
That's always been true and still is, so I didn't dwell on it. Only a
per-buffer lock is held while doing either input or output.
On Mon, 2005-02-21 at 18:01 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
[I'm assuming that there are no system-wide locks held across I/Os, that
bit seems a bit unclear from the description]
That's always been true and still is, so I didn't dwell on it. Only a
per-buffer
Simon Riggs [EMAIL PROTECTED] writes:
...but do you agree with my comments on the lack of scalability in cache
miss situations?
No. Grabbing a lock during a cache miss is the least of your worries;
you're going to do I/O, or at least a kernel call, so it hardly matters
as long as you're not
Simon Riggs [EMAIL PROTECTED] writes:
This design seems to be a clear improvement on the current design. I am
still encouraged that the freelist structures should be subdivided into
many smaller pieces, thereby producing finer grained locks (the earlier
bufferpools proposal).
As I already
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I think we just need to _favor_ UTF8.
I agree.
The question is where are we
favoring Unicode rather than UTF8?
It's the canonical name of the encoding, both in the code and the docs.
regression=# create database e
Magnus, where are we on this? Seems we should allow unicode encoding
and just not unicode locale in pginstaller.
Also, Unicode is changing to UTF-8 in 8.1.
---
Tatsuo Ishii wrote:
I do understand the problem, but don't
Applied.
---
Bruce Momjian wrote:
Nicolai Tufar wrote:
Hello all,
I would like to submit my changes to src/port/snprintf.c to
enable %n$ format placeholder replacement in snprintf() and
vsnprintf(). Additionally
Presently the planner considers left-deep, right-deep, and bushy plans
(i.e. it will consider plans in which the outer operand of a join is a
join, the inner operand is a join, or both operands are joins). It is a
fairly standard heuristic in the literature to restrict the search to
left-deep
Is there a way to recall the previous command in psql? Obviously, up
arrow or Ctrl-P using readline and the default readline bindings is
close, but it recalls the previous _line_ of input. That is not at all
the same thing in the case of a multiple line command, for example.
If there is no way
In [EMAIL PROTECTED], on 02/22/05
at 03:26 PM, Neil Conway [EMAIL PROTECTED] said:
Is there a way to recall the previous command in psql? Obviously, up
arrow or Ctrl-P using readline and the default readline bindings is
close, but it recalls the previous _line_ of input. That is not at all
On Tue, Feb 22, 2005 at 03:26:52PM +1100, Neil Conway wrote:
Is there a way to recall the previous command in psql? Obviously, up
arrow or Ctrl-P using readline and the default readline bindings is
close, but it recalls the previous _line_ of input. That is not at all
the same thing in the
On Sun, Feb 20, 2005 at 10:50:35PM -0500, Greg Stark wrote:
Peter Bierman [EMAIL PROTECTED] writes:
I think the intent of fsync() is closer to what you describe, but the
convention is that fsync() hands responsibility to the disk hardware.
The convention was also that the hardware
Neil Conway [EMAIL PROTECTED] writes:
Presently the planner considers left-deep, right-deep, and bushy plans
(i.e. it will consider plans in which the outer operand of a join is a
join, the inner operand is a join, or both operands are joins). It is a
fairly standard heuristic in the
Tom Lane wrote:
Yes, and it's been rejected. The notion is obviously bogus; it amounts
to assuming that every database is a star schema with only one core table.
Interesting; yes, I suppose that's true.
Once we get into GEQO territory, we are using the left-deep-only
heuristic because that's the
Neil Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
Once we get into GEQO territory, we are using the left-deep-only
heuristic because that's the only kind of plan GEQO can construct.
I think most applications would prefer an exhaustive, deterministic
search of a subset of the search
On Tue, 22 Feb 2005 15:26:52 +1100, Neil Conway [EMAIL PROTECTED] wrote:
Is there a way to recall the previous command in psql? Obviously, up
arrow or Ctrl-P using readline and the default readline bindings is
close, but it recalls the previous _line_ of input. That is not at all
the same
Neil Conway [EMAIL PROTECTED] writes:
- when a multiple-line command is recalled, how should it be presented
in the psql input buffer? Perhaps we could strip newlines from recalled
command text, so that the recalled command would fit on a single line.
That fails on at least three cases: --
35 matches
Mail list logo
