On Sun, Mar 15, 2009 at 4:39 AM, Tom Lane wrote:
> Whilst poking at bug #4702 I noticed that PG CVS HEAD rejects use of
> AD/BC notation, as well as CC (separate century) fields, in combination
> with ISO-style day numbers. I don't see the point of this. It's
> historically inaccurate, no doubt,
On Sat, 2009-03-14 at 12:25 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > On Sat, 2009-03-14 at 11:47 -0400, Tom Lane wrote:
> >> ... Aside from the implementation costs of making
> >> it variable, there is the oft repeated refrain that Postgres has too
> >> many configuration knobs alrea
This is just the fix for hstore's silent truncation, including
doc patch and regression test. Actual new functionality will
follow later in another patch.
--
Andrew.
Index: contrib/hstore/hstore.h
===
RCS file: /projects/cvsroot/pgs
Josh Berkus wrote:
> However, at Greenplum I remember determining that larger PG block sizes,
> if matched with larger filesystem block sizes did significantly help on
> performance of data warehouses which do a lot of seq scans -- but that
> our ceiling of 32K was still too small to really
Josh Berkus writes:
> What I want to be able to do is to set different bunches of resource
> management settings for various non-login inherited roles, and be able
> to choose profiles via a SET ROLE. The reason to do this, btw, instead
> of defining various login roles, is that different logi
Josh Berkus writes:
> As an hstore user, I'd be fine with simply limiting it to 64K (or, heck,
> 8K) and throwing an error. I'd also be fine with limiting keys to 255
> bytes, although we'd have to warn people.
Yeah, 255 might well be more of a problem than the other limit. We
could move to s
Tom Lane wrote:
I wrote:
Andrew Dunstan writes:
In my original patch, I looked at all the dependencies of a candidate
item ansd compared them with the dependencies of the running items to
see if there was a potential locking clash. However, Tom in his
admirable reworking of my patc
Tom Lane wrote:
Gregory Stark writes:
So has anyone here done any experiments with live systems with different block
sizes? What were your experiences?
Mark tested this back in the OSDL days. His findings on DBT2 was that
the right *combination* of OS and PG blocksizes gave up to a 5%
per
--- Sorry about the previous mail; that did not have the proper subject line
(for no fault of mine)
Hi All,
Acting on a customer's report I analyzed this bug, and have found a fix
for it. It is not a critical error, but it definitely is a bug, and can have
security implications.
This er
Jim,
Yes, I think aliasing (especially at the table level) would be handy.
We already *have* table aliases. They're called "views". What we don't
have is column aliases.
However, for column aliases to be really useful for more than just
application refactoring, we'd have to support calc
Hi All,
Acting on a customer's report I analyzed this bug, and have found a fix
for it. It is not a critical error, but it definitely is a bug, and can have
security implications.
This error is raised from syslogger.c, and since this sub-process is not
responsible for any backend communic
Tom Lane wrote:
I wrote:
If we wanted to keep the lengths in the same 32 bits they presumably
occupy now, what about splitting 8/24 (=> 255 bytes for key, 24MB for
value)?
Sigh, fingers faster than brain today. A 24-bit length field could
represent lengths up to 16MB, not 24MB. Still, it see
Gregory Stark wrote:
Guillaume Smet writes:
On Fri, Mar 13, 2009 at 2:39 AM, Josh Berkus wrote:
SET ROLE special WITH SETTINGS
... or similar; I'd need to find an existing keyword which works.
Perhaps something like "SET ROLE special NEW SESSION;".
It solves a problem mentioned by Tom as
On Sat, Mar 14, 2009 at 01:39:35PM -0400, Tom Lane wrote:
> Whilst poking at bug #4702 I noticed that PG CVS HEAD rejects use of
> AD/BC notation, as well as CC (separate century) fields, in
> combination with ISO-style day numbers. I don't see the point of
> this. It's historically inaccurate, n
Whilst poking at bug #4702 I noticed that PG CVS HEAD rejects use of
AD/BC notation, as well as CC (separate century) fields, in combination
with ISO-style day numbers. I don't see the point of this. It's
historically inaccurate, no doubt, but so is use of Gregorian counting.
So I suggest the att
On Mar 13, 2009, at 4:47 PM, Tom Lane wrote:
Or we could increase the size of hstore values so as to provide more
than 32 bits total for this, but that would presumably be pessimal for
all existing applications; there is evidently no one using more than
64K, or we'd have heard complaints before.
On Mar 4, 2009, at 5:07 PM, Josh Berkus wrote:
Back on that track, I'd like to see a facility whereby we could
provide an alias (or synonym, to use a nearby subject) columns and
other objects. That would help to overcome naming glitches without
breaking things quite so much.
Believe it or
"Joshua D. Drake" writes:
> On Sat, 2009-03-14 at 11:47 -0400, Tom Lane wrote:
>> ... Aside from the implementation costs of making
>> it variable, there is the oft repeated refrain that Postgres has too
>> many configuration knobs already.
> Well that "too many knobs" argument doesn't apply to t
On Sat, 2009-03-14 at 11:47 -0400, Tom Lane wrote:
> Gregory Stark writes:
> > So has anyone here done any experiments with live systems with different
> > block
> > sizes? What were your experiences?
>
> That should really have been the *first* question. We are not going to
> make this a tuna
Gregory Stark writes:
> So has anyone here done any experiments with live systems with different block
> sizes? What were your experiences?
That should really have been the *first* question. We are not going to
make this a tunable unless there is some pretty strong evidence that
it's worth twid
On Sat, 2009-03-14 at 15:29 +, Gregory Stark wrote:
> "Joshua D. Drake" writes:
> > I think that is an understatement. I would say 99% of postgresql users
> > do NOT compile from source. Heck the only time I compile from source is
> > when I need to fix mis-configured defaults in RH packages
"Joshua D. Drake" writes:
> On Sat, 2009-03-14 at 13:53 +0100, Martijn van Oosterhout wrote:
>> On Wed, Mar 11, 2009 at 01:29:43PM +, Greg Stark wrote:
>> > The main advantage would be for circumstances such as the Windows
>> > installer where users are installing precompiled binaries. They d
On Sat, 2009-03-14 at 13:53 +0100, Martijn van Oosterhout wrote:
> On Wed, Mar 11, 2009 at 01:29:43PM +, Greg Stark wrote:
> > The main advantage would be for circumstances such as the Windows
> > installer where users are installing precompiled binaries. They don't
> > get an opportunity to ch
On Wed, Mar 11, 2009 at 01:29:43PM +, Greg Stark wrote:
> The main advantage would be for circumstances such as the Windows
> installer where users are installing precompiled binaries. They don't
> get an opportunity to choose the block size at all. (Similarly for
> users of binary-only commerc
24 matches
Mail list logo
