The todo list says, as follows:
* Binary Data
o Add security checks for large objects
http://wiki.postgresql.org/wiki/Todo#Binary_Data
Is anyone working on? or interested in?
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Kenneth Marshall wrote:
> What is not clear from Stefen's function listing is how the 8.4
> server could issue 33% more XLogInsert() and CopyReadLine()
> calls than the 8.3.7 server using the same input file.
I thought those were profiling numbers -- the number of times a timer
checked what w
"Kevin Grittner" wrote:
> I've got to go keep an appointment
Sorry about that. Back now. Anything else I can do to help with
this?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
On Thu, Jun 18, 2009 at 05:20:08PM -0400, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
> > Any objections if I add:
> > http://archives.postgresql.org/pgsql-performance/2009-06/msg00215.php
> > to the (currently empty) list of open items for 8.4?
>
> I am unable to duplicate any slowdown on thi
Greg Stark writes:
> We could add an integer prefix to the char() datatype
> with the "total" length and then just not include the spaces. But that
> would make it not binary compatible with text -- which would mean
> implementing a whole bunch of casts and operators.
Um, it's already not binary
Tom Lane wrote:
> It'd be useful first off to figure out if it's a CPU or I/O issue.
> Is there any visible difference in vmstat output? Also, try turning
> off autovacuum in both cases, just to see if that's related.
Both took slightly longer with autovacuum off, but probably just
within th
On Thu, Jun 18, 2009 at 10:03 PM, Simon Riggs wrote:
>
> The overall problem is that we expect the Datum's of a datatype to know
> how to display themselves without any access to metadata.
Yes
> Another way of looking at this might be that we need a default FORMAT
> specifier associated with a co
"Kevin Grittner" writes:
> Tom Lane wrote:
>> I am unable to duplicate any slowdown on this test case.
> [ Kevin can ]
It'd be useful first off to figure out if it's a CPU or I/O issue.
Is there any visible difference in vmstat output? Also, try turning
off autovacuum in both cases, just to s
Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> Any objections if I add:
>>
http://archives.postgresql.org/pgsql-performance/2009-06/msg00215.php
>> to the (currently empty) list of open items for 8.4?
>
> I am unable to duplicate any slowdown on this test case. AFAICT
> 8.4 and 8.3 branch t
Peter Eisentraut wrote:
> On Saturday 06 June 2009 16:21:22 Bruce Momjian wrote:
> > Bruce Momjian wrote:
> > > Now that pg_migrator is in beta
> > > (http://pgfoundry.org/frs/?group_id=1000235), I was wondering if we want
> > > to mention pg_migrator anywhere in our docs or release notes? Josh
>
Bruce Momjian writes:
> Tom Lane wrote:
>> What would make sense to me is for libpq to provide the *code* for this,
>> but then leave it up to the client application whether to actually call
>> it; if not the behavior stays the same as before. Aside from
>> Itagaki-san's objections, that eliminat
Tom Lane wrote:
> Itagaki Takahiro writes:
> > Peter Eisentraut wrote:
> >> On Wednesday 17 June 2009 14:29:26 Heikki Linnakangas wrote:
> >>> We currently require that you set client_encoding correctly, or you get
> >>> garbage in psql and any other tool using libpq. How about setting
> >>> clie
Stefan Kaltenbrunner writes:
> Any objections if I add:
> http://archives.postgresql.org/pgsql-performance/2009-06/msg00215.php
> to the (currently empty) list of open items for 8.4?
I am unable to duplicate any slowdown on this test case. AFAICT
8.4 and 8.3 branch tip are about the same speed;
On Thu, 2009-06-18 at 12:58 -0400, Tom Lane wrote:
> "Kevin Grittner" writes:
> > Tom Lane wrote:
> >> It would be way nicer if we could strip trailing blanks on storage,
> >> and then figure a way to either reconstitute them on output
>
> > How about pushing it even farther back -- always ke
Any objections if I add:
http://archives.postgresql.org/pgsql-performance/2009-06/msg00215.php
to the (currently empty) list of open items for 8.4?
A 25-30% performance regression in our main bulk loading mechanism
should at least be explained before the release...
Stefan
--
Sent via pgs
I wrote:
> One thing I notice is that the "table" and "with" entries are not coming
> out as intended. The file names are all caps:
> -rw-r--r-- 1 tglusers 18 Jun 12 01:37 WITH.7
> -rw-r--r-- 1 tglusers 18 Jun 12 01:37 TABLE.7
> and the content surely isn'
Peter Eisentraut writes:
> I noticed that the rc1 tarball does not contain man pages for
> CREATE/ALTER/DROP FOREIGN DATA WRAPPER/SERVER/USER MAPPING.
Just eyeballing the files, I notice that those ref pages seem not
to contain this boilerplate:
7
which is mostly(?) present in others. Maybe
On 06/18/2009 02:42 AM, Pavel Golub wrote:
Now to implement customer's desire in PostgreSQL there are two ways:
1. Each script must be executed in the separate connection context
2. Each script must be executed inside critical section, in other
words current scipt must block others until COMMIT
Peter Eisentraut writes:
> I noticed that the rc1 tarball includes scanner files that are built with an
> older flex version that generates warnings with our default compilation
> flags.
> Since I have been running with -Werror by default for a great while now, this
> caught my attention whil
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> It would be way nicer if we could strip trailing blanks on
>>> storage, and then figure a way to either reconstitute them on
>>> output
>
>> How about pushing it even farther back -- always keep them with
>> trimmed trailing s
Peter Eisentraut writes:
> Can someone check, or remind me how the man pages end up in the tarball?
They're supposed to be built on the fly, and the file dates in the rc1
tarball do appear to match the time of tarball building. Do you get
what you expect if you build the man pages locally?
One
On Sat, 6 Jun 2009, Bruce Momjian wrote:
Having gotten no replies I assume we don't want to mention pg_migrator
in the release notes or documentation, which is fine.
I know this project has resistance to putting URL links in the
documentation. One option I was thinking about was creating som
"Kevin Grittner" writes:
> Tom Lane wrote:
>> It would be way nicer if we could strip trailing blanks on storage,
>> and then figure a way to either reconstitute them on output
> How about pushing it even farther back -- always keep them with
> trimmed trailing spaces and add trailing spaces a
> I have fixed this problem.
Thanks a lot for the fix !
>> Next time, please start a new thread for a new issue, so your issue
doesn't
>> get lost.
> Gmail has gotten the idiotic idea that changing the subject makes the
> message appear as a new thread :-(
Sorry.
This is the first posting in h
Peter Eisentraut escribió:
> Next time, please start a new thread for a new issue, so your issue doesn't
> get lost.
Gmail has gotten the idiotic idea that changing the subject makes the
message appear as a new thread :-(
--
Alvaro Herrerahttp://www.CommandPromp
On Tuesday 16 June 2009 18:16:58 genie.j...@gmail.com wrote:
> Hi,
>
> I've found the uninstallation error...
>
>
> # make uninstall
>
>
>
> n/man7/truncate.7 /usr/local/pgsql/share/man/man7/unlisten.7
> /usr/local/pgsql/share/man/man7/update.7
> /usr/local/pgsql/share/man/man7/vacuum.7
> /usr/loca
Simon Riggs escribió:
> I notice we lose on tuple access also. CHAR(n) is fixed length, but is
> treated as variable length for offsets.
Fixed character length != fixed byte length
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting,
I noticed that the rc1 tarball does not contain man pages for
CREATE/ALTER/DROP FOREIGN DATA WRAPPER/SERVER/USER MAPPING. But it does
contain man pages for TABLE and WITH, so it appears to be 8.4 material.
Can someone check, or remind me how the man pages end up in the tarball?
--
Sent via pg
I noticed that the rc1 tarball includes scanner files that are built with an
older flex version that generates warnings with our default compilation flags.
Since I have been running with -Werror by default for a great while now, this
caught my attention while testing the tarball. Are we tracki
On Sunday 14 June 2009 23:31:48 Erik Rijkers wrote:
> http://www.postgresql.org/docs/8.4/static/release-8-4.html
>
> In the current 8.4rc1 release notes, it says (point 2):
>
> "Common Table Expressions and Recursive Joins"
>
>
> It would be better to replace this by:
>
> "Common Table Expressi
On Thu, 2009-06-18 at 09:59 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > Why is bcTruelen being called so many *more* times?
>
> I think you have misunderstood the context.
err, no, I just misread the original text. Possibly a worse error :-?
> It would be way nicer if we could strip trail
Tom Lane wrote:
> It would be way nicer if we could strip trailing blanks on storage,
> and then figure a way to either reconstitute them on output
How about pushing it even farther back -- always keep them with
trimmed trailing spaces and add trailing spaces as required in
operator functions
Simon Riggs writes:
> Why is bcTruelen being called so many *more* times?
I think you have misunderstood the context. The char(n) code is defined
to store trailing blanks (up to n) but to disregard the trailing blanks
during comparisons. bcTrueLen is invoked during comparisons (not during
stora
* Simon Riggs:
> On Thu, 2009-06-18 at 15:09 +0200, Stefan Kaltenbrunner wrote:
>
>> the testcase discusses here is indeed CHAR(n) vs. VARCHAR.
>
> OK, thanks for pointing out my error.
But I think your point still makes sense. Is it really necessary to
determine the unpadded length for a query
On Saturday 06 June 2009 16:21:22 Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Now that pg_migrator is in beta
> > (http://pgfoundry.org/frs/?group_id=1000235), I was wondering if we want
> > to mention pg_migrator anywhere in our docs or release notes? Josh
> > Berkus is already mentioning it
Pavel Golub writes:
> [ proposal involving ]
> SWITCH TRANSACTION first; -- switch context
> So, what do you think guys?
No chance :-(. The amount of work that would be required is *vastly*
out of proportion to any possible benefit. Use multiple connections.
regards, t
On Thu, 2009-06-18 at 15:09 +0200, Stefan Kaltenbrunner wrote:
> the testcase discusses here is indeed CHAR(n) vs. VARCHAR.
OK, thanks for pointing out my error.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (
Simon Riggs wrote:
On Thu, 2009-06-18 at 15:14 +0300, Marko Kreen wrote:
On 6/18/09, Simon Riggs wrote:
On Tue, 2009-06-16 at 10:23 -0400, Tom Lane wrote:
> Speaking of which, what about some performance numbers? Like Heikki,
> I'm quite suspicious of whether there is any real-world gain t
On Thu, 2009-06-18 at 15:14 +0300, Marko Kreen wrote:
> On 6/18/09, Simon Riggs wrote:
> > On Tue, 2009-06-16 at 10:23 -0400, Tom Lane wrote:
> > > Speaking of which, what about some performance numbers? Like Heikki,
> > > I'm quite suspicious of whether there is any real-world gain to be had
On 6/18/09, Simon Riggs wrote:
> On Tue, 2009-06-16 at 10:23 -0400, Tom Lane wrote:
> > Speaking of which, what about some performance numbers? Like Heikki,
> > I'm quite suspicious of whether there is any real-world gain to be had
> > from this approach.
>
>
> It has been "lore" for some tim
On Tue, 2009-06-16 at 10:23 -0400, Tom Lane wrote:
> Speaking of which, what about some performance numbers? Like Heikki,
> I'm quite suspicious of whether there is any real-world gain to be had
> from this approach.
It has been "lore" for some time that VARCHAR is cheaper than
VARCHAR(n), so I
Fujii Masao wrote:
Here're the patches to fix typos in source comment.
typo_postgres.patch should be backported to v8.2 and v8.3.
Thanks, applied.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
--On Mittwoch, Juni 17, 2009 16:44:53 +0300 Peter Eisentraut
wrote:
I think you should design this with a bit wider scope. Instead of just
"all tables in this schema", think "all tables satisfying some
condition". It has been requested, for example, to be able to grant on
all tables that m
Hi,
Here're the patches to fix typos in source comment.
typo_postgres.patch should be backported to v8.2 and v8.3.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
typo_pgstandby.patch
Description: Binary data
typo_postgres.patch
Description
On Tue, 2009-06-16 at 00:24 -0400, Robert Haas wrote:
> There's not much point taking the length of the word
Not sure why we need to be calculating the length here anyway. ISTM that
there is no need to reconfirm the length of the data, since it is
already checked to be that length at insert.
Wh
On Wednesday 17 June 2009 20:27:20 Robert Haas wrote:
> What to do about wildcards is a stickier wicket, and maybe we need to
> decide that first, but I really don't think we should be discouraging
> anyone from investigating this stuff and trying to come up with good
> solutions. There will alway
On Thursday 18 June 2009 06:01:13 to...@tuxteam.de wrote:
> One of the common pitfalls of XML is that designers think first in terms
> of the XML representation before being clear on the abstract structure
> of what they want to represent
The other aspect is that designing a useful XML format is p
47 matches
Mail list logo
