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:
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:
> 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
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:
> 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
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
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
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
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
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
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
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
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-
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
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
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:
> [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-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
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
>> 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
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
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
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
>> > 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
-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
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
>
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
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
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
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, 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 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
> >> 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
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
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
35 matches
Mail list logo
