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 commercial
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 choose
Joshua D. Drake j...@commandprompt.com 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
On Sat, 2009-03-14 at 15:29 +, Gregory Stark wrote:
Joshua D. Drake j...@commandprompt.com 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
Gregory Stark st...@enterprisedb.com 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
On Sat, 2009-03-14 at 11:47 -0400, Tom Lane wrote:
Gregory Stark st...@enterprisedb.com 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
Joshua D. Drake j...@commandprompt.com 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
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
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
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
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, no
Gregory Stark wrote:
Guillaume Smet guillaume.s...@gmail.com writes:
On Fri, Mar 13, 2009 at 2:39 AM, Josh Berkus j...@agliodbs.com 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;.
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
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
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
--- 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
Tom Lane wrote:
Gregory Stark st...@enterprisedb.com 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
Tom Lane wrote:
I wrote:
Andrew Dunstan and...@dunslane.net 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
Josh Berkus j...@agliodbs.com 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
Josh Berkus j...@agliodbs.com 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
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
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:
On Sat, 2009-03-14 at 12:25 -0400, Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com 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
On Sun, Mar 15, 2009 at 4:39 AM, Tom Lane t...@sss.pgh.pa.us 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
24 matches
Mail list logo
