"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> Hrm, I tried it on my x86_64 (quad core 2.66ghz, sorry no exotic
> machines here :)) and did not see any real noticeable difference
> between the two...
Thanks. That confirms my feeling that I was seeing some weird artifact
on my own x86_64 box.
On Fri, Aug 29, 2008 at 1:16 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> In theory the above implementation of newNode should be a clear win,
> so I'm thinking this result must be an artifact of some kind. I'm
> going to go try it on PPC and HPPA machines next; does anyone want to
> try it on someth
I wrote:
> In theory the above implementation of newNode should be a clear win,
> so I'm thinking this result must be an artifact of some kind. I'm
> going to go try it on PPC and HPPA machines next; does anyone want to
> try it on something else?
Repeating the explain test on several machines, I
Robert Treat wrote:
> On Thursday 28 August 2008 13:08:58 Alvaro Herrera wrote:
> > This should make life easier for tools trying to find the config file
> > each setting is from (and possibly edit it).
>
> If I have read this patch right, anything commented out (aka all of our
> default values)
On Thursday 28 August 2008 13:08:58 Alvaro Herrera wrote:
> Hi,
>
> Here's a patch to add source file and line numbers to GUC variables.
> Basically this makes pg_settings look like this:
>
> This should make life easier for tools trying to find the config file
> each setting is from (and possibly
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I considered that one, but since part of my argument is that inlining
>> this is a waste of code space, it seems like a better inlining
>> technology isn't really the answer.
> The compiler presumably has the intelligence and the co
On Fri, 29 Aug 2008 18:07:36 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
> I'm starting to think D'Arcy's on the right track here.
Is that the train coming? :-)
> Keep in mind the use case here is as Alvaro says, just a user convenience
> thing. It's not meant for file dumps and loads. If we
daveg wrote:
> Attached is a the followon patch for pg_dumpall and docs to match pg_dump.
Thanks, committed. (The only change I did was to correct the alignment
in help output.)
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, C
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Joshua Drake escribió:
>
>> I am trying to understand why we are having a client do this? If you
>> want some other type of output, script it.
>
> Convenience. If we had real rst output, we could just copy'n paste into
> Trac or other systems.
I'm sta
Here's the latest window functions patch against HEAD. It seems to be
ready for the September commit fest, as added documents, WINDOW clause
feature and misc tests. I guess this would be the window functions
feature freeze for 8.4. The remaining feature will be implemented for
the later release.
T
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I cannot reproduce any problem with a vpath build. Make sure you have
> > really cleaned the source tree from previous rounds. Some of the files
> > involved are symlinks, which might confuse make.
>
> "make maintainer-clean" b
Peter Eisentraut wrote:
> Alvaro Herrera wrote:
>> I'm finding that this patch is needed to make this build on VPATH:
>
> I cannot reproduce any problem with a vpath build. Make sure you have
> really cleaned the source tree from previous rounds. Some of the files
> involved are symlinks, whi
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I cannot reproduce any problem with a vpath build. Make sure you have
> really cleaned the source tree from previous rounds. Some of the files
> involved are symlinks, which might confuse make.
"make maintainer-clean" before pulling this update wo
Joshua Drake escribió:
> I am trying to understand why we are having a client do this? If you
> want some other type of output, script it.
Convenience. If we had real rst output, we could just copy'n paste into
Trac or other systems.
Convenience is why we have psql at all. Otherwise, surely ev
Alvaro Herrera wrote:
I'm finding that this patch is needed to make this build on VPATH:
I cannot reproduce any problem with a vpath build. Make sure you have
really cleaned the source tree from previous rounds. Some of the files
involved are symlinks, which might confuse make.
Index: sr
On Fri, 29 Aug 2008 11:23:50 -0500
"Jaime Casanova" <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 29, 2008 at 8:45 AM, D'Arcy J.M. Cain <[EMAIL PROTECTED]>
> wrote:
> >
> > I'm surprised that we don't have a general option to escape special
> > characters. Perhaps that's the next small enhancement.
>
On Fri, Aug 29, 2008 at 8:45 AM, D'Arcy J.M. Cain <[EMAIL PROTECTED]> wrote:
>
> I'm surprised that we don't have a general option to escape special
> characters. Perhaps that's the next small enhancement.
>
> darcy=# \pset escape \
>
this looks like we are trying to make cosmetic magic instead o
Peter Eisentraut wrote:
> Log Message:
> ---
> Remove all traces that suggest that a non-Bison yacc might be supported, and
> change build system to use only Bison. Simplify build rules, make file names
> uniform. Don't build the token table header file where it is not needed.
I'm find
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There may
>> be no very good way to do that without maintaining some shared state,
>> ie the last page handed out.
> We could put an extra field on the FSM root page. Hmm, it doesn't
> actually need to be a single global field, s
Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
One idea, we could scan the rest of the current page and use the first match.
Another, given the way your tree structure works you can also descend the tree
with a "target" page. You can find the first page with enough free space after
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Patch attached. I'm using a magic OID "1" in pg_cast.castfunc field to
mark these extra I/O conversion casts.
Ugh. That's really unacceptable (doesn't it make the oidjoins
regression test fail?),
Yeah, it does if you create a ca
Gregory Stark <[EMAIL PROTECTED]> writes:
> One idea, we could scan the rest of the current page and use the first match.
> Another, given the way your tree structure works you can also descend the tree
> with a "target" page. You can find the first page with enough free space after
> the target p
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Patch attached. I'm using a magic OID "1" in pg_cast.castfunc field to
> mark these extra I/O conversion casts.
Ugh. That's really unacceptable (doesn't it make the oidjoins
regression test fail?),
I think that as things stand at the moment, you
On Fri, 29 Aug 2008 06:55:45 -0400
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
> On Fri, 29 Aug 2008 01:29:14 -0400
> I think that your scan may have been a bit too cursory. Those
> characters, while significant in ReST, only matter when used in very
> specific ways. The following works just fi
Peter Eisentraut wrote:
Michelle Caisse wrote:
gcov gets confused when source files are generated. I eliminated
src/backend/bootstrap and ../parser from coverage analysis to avoid
errors of this type.
The problem with those files is that the source file contains lines like this:
#line 1042 "y
Since 8.3, the system provides automatic I/O conversion casts between
the built-in string types and other types, but there's currently no way
for a user to declare additional casts using the I/O functions. You can
always create a simple SQL function to do that, but it seems like we
should pro
Since 8.3, the system provides automatic I/O conversion casts between
the built-in string types and other types, but there's currently no way
for a user to declare additional casts using the I/O functions. You can
always create a simple SQL function to do that, but it seems like we
should provi
On Fri, 29 Aug 2008 01:29:14 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Hmm ... the patch works for data that contains no backslashes,
> asterisks, backquotes, vertical bars, nor underscores. Nor perhaps
> other special characters that I might've missed in one cursory scan of
> the ReST spec. I'
As stated above this format is mainly good for copy paste and may require
occasional manual tweaking.
Users should be people who use psql in their everyday work and on the other
hand need to publish data from database in some other places. Would you
please bring examples of some widespread applicat
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Fortunately there's an easy fix for that. If we optimize
> RecordAndGetPageWithFreeSpace so that it will always return the next page if
> it
> has enough space, we'll be doing sequential I/O again. That's trivial as long
> as the next heap page is
Le Saturday 23 August 2008, D'Arcy J.M. Cain a écrit :
> On Thu, 21 Aug 2008 21:04:07 -0400
>
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote:
> > > There's still the question of whether this covers any needs that aren't
> > > met just as well by XML or CSV output formats.
> >
> > Well, we could rem
Le Friday 29 August 2008, Greg Smith a écrit :
> On Fri, 29 Aug 2008, Tom Lane wrote:
> > You're ignoring the fact that D'Arcy's patch doesn't output valid ReST.
> > It outputs something that might pass for ReST, but only so long as there
> > are no special characters in the data.
>
> I agree that
The way my rewritten FSM works at the moment is that pages are handed
out of the FSM in random order, to spread the load of multiple backends
to different pages. That's good for spreading the load, but it occurred
to me while observing a test case that inserts a lot of rows to an
almost empty t
On Fri, 29 Aug 2008, Tom Lane wrote:
the patch works for data that contains no backslashes, asterisks,
backquotes, vertical bars, nor underscores.
These characters don't show up very much in real world data. You'll find
[-.,:;[EMAIL PROTECTED]&()"] in just about everything; those would be a
34 matches
Mail list logo
