Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > Brendan Jurd wrote:
> >> To me, this message sounds like you're setting the width of a single
> >> column, when in fact you're setting the target *total* width of the
> >> table. I think this message would be more clear if i
Decibel! wrote:
we can just look at
the hit rate for the object. But we'd also need stats for how often we
find pages for a relation in the OS cache, which no one has come up with
a good method for.
Makes me wonder if we could (optionally, I guess, since timing
stuff is apparently slow on so
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Brendan Jurd wrote:
>> To me, this message sounds like you're setting the width of a single
>> column, when in fact you're setting the target *total* width of the
>> table. I think this message would be more clear if it read "Target
>> output width ..
Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
On Wed, 2008-04-23 at 12:07 -0400, Tom Lane wrote:
To be acceptable, a GIT patch would have to be optional and it
...
I was considering a new pg_index column. Or else we'd have to fix
the storage-parameter infrastructure to support restr
Simon Riggs wrote:
> GIT significantly reduces the size of clustered indexes, greatly
> improving the number of index pointers that can be held in memory for
> very large indexes. That translates directly into a reduction in I/O for
> large databases on typical hardware, for primary operations, fil
Joshua D. Drake wrote:
> On Wed, 23 Apr 2008 09:24:42 -0700
> "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> >
> > O.k. here is version 3 of the patch.
> >
> > It is the same patch except that on standard connect it emits the
> > client version. It does not emit the server version u
Brendan Jurd wrote:
> This is a very cool feature! Looking through the patch I did have a
> few thoughts.
>
> This is definitely going to introduce merge conflicts with my
> printTable API patch. That's not a problem, just a "note to self"
> that when/if this patch goes in I'll have to submit a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 24, 2008 at 8:30 AM, Bruce Momjian
wrote:
> I have moved this discussion to hackers in hopes of getting more
> feedback, and moved the patch to a static URL:
>
Hi Bruce,
This is a very cool feature! Looking through the patch I did have
I have moved this discussion to hackers in hopes of getting more
feedback, and moved the patch to a static URL:
ftp://momjian.us/pub/postgresql/mypatches/wrap
This patch adds a new '\pset format wrapped' mode that wraps long values
to fit the table on the user's screen, or in '\pset colum
On Wed, 23 Apr 2008 17:54:45 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Right. I suggest you open the file in "meld" which allows you to
> easily remove the offending extraneous difference. Of course, you
> can do it in Vim or Emacs directly, but I don't think Joe can do
> anything of th
Joshua D. Drake wrote:
> On Wed, 23 Apr 2008 17:44:43 -0400
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> > Joshua D. Drake wrote:
>
> Ahh o.k. Now I have a complaint. :) I happily removed the whitespace
> where I saw this, "%s \n" (for example) but the whitespace above is for
> readability. Co
On Wed, 23 Apr 2008 17:44:43 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Joshua D. Drake wrote:
>
> > ! puts(_("\n"));
> > ! puts(_("You are using psql, the
> > command-line interface to PostgreSQL.\n")); !
> > puts(_("\tFor SQL help t
Joshua D. Drake wrote:
> ! puts(_("\n"));
> ! puts(_("You are using psql, the command-line interface
> to PostgreSQL.\n"));
> ! puts(_("\tFor SQL help type \\h or \\help ."));
On Wed, 23 Apr 2008 17:22:10 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Joshua D. Drake wrote:
> > On Wed, 23 Apr 2008 10:48:24 -0700
> > "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> >
> > O.k. I *think* this should do it.
>
> Whitespace still broken
Well maybe if we just declared that
Joshua D. Drake wrote:
> On Wed, 23 Apr 2008 10:48:24 -0700
> "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
>
> O.k. I *think* this should do it.
Whitespace still broken
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom De
On Wed, 23 Apr 2008 10:48:24 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
O.k. I *think* this should do it.
Added word Some
Version shows up no matter what
Server version shows up only if:
major or minor version doesn't match (same same as previous behavior)
Joshua D. Drake
--
The Postg
I wrote:
> After further thought about this, and about the new "ForceToNull"
> expression node that I was suggesting, I have a more radical proposal
> in mind: let's get rid of join alias variables, instead of expanding
> their use.
I've been studying this idea more, and it seems workable and usef
On Wed, 2008-04-23 at 14:06 -0400, Tom Lane wrote:
> I think storage parameter is no good also, given the current design that
> assumes those can be changed on-the-fly. It'd be okay to GIT-ify an
> existing index, perhaps, but not the other way round.
>
> I was considering a new pg_index column.
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Wed, 2008-04-23 at 12:07 -0400, Tom Lane wrote:
>> To be acceptable, a GIT patch would have to be optional and it
>> would have to expose in the catalogs whether a given index was lossy
>> in this way or not (so that the planner could know whether a plan
On Wed, 23 Apr 2008 17:28:04 -
"Greg Sabino Mullane" <[EMAIL PROTECTED]> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
> > WARNING: Server version 8.2, psql version 8.4.
> > psql features may not work.
>
> Can we say "Some psql features..."? the lowercase looks odd.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> WARNING: Server version 8.2, psql version 8.4.
> psql features may not work.
Can we say "Some psql features..."? the lowercase looks odd.
> I left off server version because there doesn't seem to be a
> reason to have it except if the server
On Wed, 2008-04-23 at 12:07 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I don't see the "returns index keys" idea as being killed by or killing
> > this concept. Returning keys is valid and useful when we can, but there
> > are other considerations that, in some use cases,
On Wed, 23 Apr 2008 12:38:22 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Joshua D. Drake wrote:
>
> > O.k. here is version 3 of the patch.
> >
> > It is the same patch except that on standard connect it emits the
> > client version. It does not emit the server version unless their is
> > a
Joshua D. Drake wrote:
> O.k. here is version 3 of the patch.
>
> It is the same patch except that on standard connect it emits the
> client version. It does not emit the server version unless their is a
> mismatch. Does that make sense?
But you didn't fix any of the whitespace issues I mentione
On Wed, 23 Apr 2008 09:24:42 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> O.k. here is version 3 of the patch.
>
> It is the same patch except that on standard connect it emits the
> client version. It does not emit the server version unless their is a
> mismatch. Does that ma
Hello,
O.k. here is version 3 of the patch.
It is the same patch except that on standard connect it emits the
client version. It does not emit the server version unless their is a
mismatch. Does that make sense?
Sincerely,
Joshua D. Drake
--
The PostgreSQL Company since 1997: http://www.comm
Simon Riggs <[EMAIL PROTECTED]> writes:
> I don't see the "returns index keys" idea as being killed by or killing
> this concept. Returning keys is valid and useful when we can, but there
> are other considerations that, in some use cases, will be a dominant
> factor.
The patch as-submitted was a
On Wed, 2008-04-09 at 20:30 -0400, Tom Lane wrote:
> * GIT (Grouped Index Tuple) indexes, which achieve index space savings
> in btrees by having a single index tuple represent multiple heap tuples
> (on a single heap page) containing a range of key values. I am not sure
> what the development st
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Can anybody recall a reason for why the do_restart() function in pg_ctl
> copies a lot of code almost right off from do_stop(), instead of just
> having that code exactly the same as do_stop() and factored out? (Like
> it does for do_start() already)
>
On Tue, 2008-04-08 at 17:10 -0400, Tom Lane wrote:
> What seems possibly more useful is to reintroduce \cwait (or hopefully
> some better name) and give it the semantics of "wait for a response from
> any active connection; switch to the first one to respond, printing its
> name, and print its res
Can anybody recall a reason for why the do_restart() function in pg_ctl
copies a lot of code almost right off from do_stop(), instead of just
having that code exactly the same as do_stop() and factored out? (Like
it does for do_start() already)
I see the point in dealing with the very first branch
> > > * If there is not a version mismatch, psql tells you nothing but
> > > ask for help if you need it.
> >
> > That was NOT part of the agreement. The version line should stay.
>
> Why do we care, if the version matches? Not that I am feeling like
> fighting about it but it seems just a wa
> > The optimizer could then use a different (much lower) value of
> > random_page_cost for tables for which "cache priority" is set
> > highest since it would know.
>
> "cache priority" to me sounds like we're trying to influence caching
> behavior, which isn't what's happening. I do agree
Example : let's imagine a "cache priority" setting.
Which we can presume the DBA will set incorrectly because the tools
needed to set that right aren't easy to use.
LOL, yes.
Jim threw out that you can just look at the page hit percentages
instead. That's not completely true. I
Martijn van Oosterhout írta:
On Wed, Apr 23, 2008 at 10:02:37AM +0200, Zoltan Boszormenyi wrote:
But the question popped up whether PostgreSQL can be extended
to allow localized literals and apply encoding conversion the same
way as on string data. NAMEDATA can be replaced with regular TEXT
a
James Mansion wrote:
> Magnus Hagander wrote:
> > You interested in trying to code up a patch to verify that? ;)
> >
> >
> Practical reality says that I won't get to this before the next
> version of Windows is released.
> I don't want to promise something I can't deliver.
:-)
If you want to th
On Wed, Apr 23, 2008 at 10:02:37AM +0200, Zoltan Boszormenyi wrote:
> But the question popped up whether PostgreSQL can be extended
> to allow localized literals and apply encoding conversion the same
> way as on string data. NAMEDATA can be replaced with regular TEXT
> and have the same conversion
Hi,
we have a customer who shot themselves in the foot by using
table names with german accented characters in them.
The client application on the popular OS is using a single-byte
encoding (LATIN9), their dump of the original database is using
the same but no "SET client_encoding = ..." line any
38 matches
Mail list logo
