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 r
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 Instit
> >> 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
> > 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 mainta
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 through
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 re
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 assume
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
>
-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 w
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 m
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
>> 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 st
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 woul
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
> p
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 alread
Tom Lane wrote:
> Bruce Momjian 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 encoding 'utf-
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(). Ad
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 p
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 wa
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
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
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 h
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 l
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 o
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 sea
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 sa
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
