2009/6/7 Markus Wanner mar...@bluegap.ch:
However, there's no special whitespace treatment. Nor anything remotely
as clever as nearby variable renaming. There's no such magic, the
developer still needs to tell the tool what he wants.
If I understand correctly, nearby variable renaming refers
On 7 Jun 2009, at 03:27, Bruce Momjian wrote:
Grzegorz Jaskiewicz wrote:
On 6 Jun 2009, at 19:50, Tom Lane wrote:
We have five days.
I don't think we need testing, per se. The first step should be to
diff
the 8.3 and 8.4 versions of the various contrib .sql.in files and
determine what
On Sun, Jun 7, 2009 at 12:11 AM, Tom Lanet...@sss.pgh.pa.us wrote:
* intarray has removed its internal @ and @ operators. As I was
mentioning the other day, it might be the best thing to just revert
that change anyway, until we can get a better handle on the behavior
of GIN for empty arrays.
Robert Haas robertmh...@gmail.com writes:
I think it's becoming increasingly clear that pg_migrator is not for
the faint of heart; in fact, I think we should hedge references to it
with words like experimental.
Probably ...
Just to recall the history, the first pgfoundry
commit messages for
On Jun 7, 2009, at 10:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I think it's becoming increasingly clear that pg_migrator is not for
the faint of heart; in fact, I think we should hedge references to it
with words like experimental.
Probably ...
On Sat, 2009-06-06 at 12:06 -0700, Josh Berkus wrote:
On the DL380 GB system, where I'm using a lot more drives the Jignesh,
I see a performance change of under 5%. 15651.14 notpm vs 16333.32
notpm. And this is after a bit of tuning, not sure how much the out
of the box experience
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I think it's becoming increasingly clear that pg_migrator is not for
the faint of heart; in fact, I think we should hedge references to it
with words like experimental.
Probably ...
I'm with Robert on that one - while pg_migrator is
Simon Riggs si...@2ndquadrant.com writes:
On Sat, 2009-06-06 at 12:06 -0700, Josh Berkus wrote:
Well, Jignesh and I identified two things which we think are special
about DBT2: (1) it uses C stored procedures, and (2) we don't think it
uses prepared plans.
If there is a performance
On Sun, Jun 7, 2009 at 5:13 PM, Tom Lanet...@sss.pgh.pa.us wrote:
In any case, what we seem to have here is evidence that there are some
cases where the new default value of default_statistics_target is too
high and you can get a benefit by lowering it. I'm not sure we should
panic about
I wrote:
* pageinspect has changed the ABI of get_raw_page() in a way that will
likely make it dump core if the function definition is migrated from
an old DB. This needs to be fixed.
[ and similarly for some other contrib modules ]
After thinking about this some more, I think that there is
On Sun, 2009-06-07 at 12:13 -0400, Tom Lane wrote:
In any case, what we seem to have here is evidence that there are some
cases where the new default value of default_statistics_target is too
high and you can get a benefit by lowering it. I'm not sure we should
panic about that. Default
Simon Riggs si...@2ndquadrant.com writes:
On Sat, 2009-06-06 at 15:44 -0400, Tom Lane wrote:
In the longer term, we need to do something else.
-1 for such radical change at this stage of release.
Uh, by longer term I meant this is something to think about for 8.5.
Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
how to trigger the failure (and therefore how to test the solution). A
naive test with two databases, one LATIN2, the other UTF8 does not
produce the error with simple text literals. Any guidance on specific
literals that would trigger the
Grzegorz Jaskiewicz wrote:
On 7 Jun 2009, at 03:27, Bruce Momjian wrote:
Grzegorz Jaskiewicz wrote:
On 6 Jun 2009, at 19:50, Tom Lane wrote:
We have five days.
I don't think we need testing, per se. The first step should be to
diff
the 8.3 and 8.4 versions of the various
On Jun 7, 2009, at 12:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I did know that EDB had been using the tool for a while, but I admit
I'm not familiar with the whole history. I had the impression that
we'd gotten a lot more serious about really making
On Sat, Jun 6, 2009 at 3:44 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I complained a couple days ago that in HEAD, vacuum is putting
very bogus values into pg_class.reltuples for indexes:
http://archives.postgresql.org/pgsql-bugs/2009-06/msg00037.php
After looking through the code a bit, I've
On Sun, Jun 7, 2009 at 7:11 PM, Robert Haasrobertmh...@gmail.com wrote:
Am I wrong to be frightened by the implications of updating this value
only once in a blue moon? Doesn't this have the potential to result
in really bad plans? Do we have any reasonable manual way of forcing
VACUUM to
On Wednesday 03 June 2009 01:55:48 Andrew Dunstan wrote:
Running recursive grep on a subversion working copy is quite nasty.
I suggest
export GREP_OPTIONS='-d skip -I --exclude=*.svn-base --exclude=tags
--exclude=*~ --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.svn
--exclude=TAGS'
--
On 6/7/09 10:56 AM, Robert Haas wrote:
OK, that's more or less what I thought, and what I intended to convey
upthread. As far as core Postgres is concerned this is a new feature,
and we haven't worked out all the kinks yet.
Yes, I'm calling it pg_migrator beta in any advocacy/PR about it.
Robert Haas robertmh...@gmail.com writes:
Am I wrong to be frightened by the implications of updating this value
only once in a blue moon?
It's not great, but I think it's probably not catastrophic either.
Keep in mind that all we need from reltuples is that the ratio
reltuples/relpages be a
Josh Berkus wrote:
On 6/7/09 10:56 AM, Robert Haas wrote:
OK, that's more or less what I thought, and what I intended to convey
upthread. As far as core Postgres is concerned this is a new feature,
and we haven't worked out all the kinks yet.
Yes, I'm calling it pg_migrator beta in any
On Sun, Jun 7, 2009 at 3:24 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Am I wrong to be frightened by the implications of updating this value
only once in a blue moon?
It's not great, but I think it's probably not catastrophic either.
Keep in mind that
Robert Haas robertmh...@gmail.com writes:
On Sun, Jun 7, 2009 at 3:24 PM, Tom Lanet...@sss.pgh.pa.us wrote:
[ thinks a bit and reads the code some more ... ] There is a
considerably safer alternative, which is to let ANALYZE update the
reltuples estimate based on the pages it sampled; which
On Sunday 31 May 2009 18:41:55 Tom Lane wrote:
AFAICS, the SQL standard demands that precision and scale fields be
non-null all the time for those data types where they make sense
(this is encoded in the CHECK CONSTRAINTs that are declared for the
various information-schema tables, see
On Sun, Jun 7, 2009 at 4:19 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jun 7, 2009 at 3:24 PM, Tom Lanet...@sss.pgh.pa.us wrote:
[ thinks a bit and reads the code some more ... ] There is a
considerably safer alternative, which is to let ANALYZE
Hello,
I have multiple files with that have very similar distributions and I'm
seeing contention when concurrent COPY's are happening against a table with
a b-tree index on the timestamp column. Each file look something like the
following:
~4M rows with timestamp1
~4M rows with timestamp2
...
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I think the cleanest solution is to document that these issues might
happen and suggest solutions.
No, the cleanest solution is to fix it before people ever see a
problem. This is trivial to do in the case of dblink and I don't
see
Tom Lane wrote:
The underlying C-level get_raw_page function is still there, but
it now expects three arguments not two, and will crash if it's
passed an int4 where it's expecting a text argument. But the old
function definition will migrate without error --- there's no way
for pg_migrator
Robert Haas wrote:
OK, that's more or less what I thought, and what I intended to convey
upthread. As far as core Postgres is concerned this is a new feature,
and we haven't worked out all the kinks yet. As long as we set
expectations accordingly, I think that's OK. You mention CVEs
Stefan Kaltenbrunner wrote:
Josh Berkus wrote:
On 6/7/09 10:56 AM, Robert Haas wrote:
OK, that's more or less what I thought, and what I intended to convey
upthread. As far as core Postgres is concerned this is a new feature,
and we haven't worked out all the kinks yet.
Yes, I'm
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I did know that EDB had been using the tool for a while, but I admit
I'm not familiar with the whole history. I had the impression that
we'd gotten a lot more serious about really making this rock solid
since Bruce took it
Peter Eisentraut pete...@gmx.net writes:
On Sunday 31 May 2009 18:41:55 Tom Lane wrote:
AFAICS, the SQL standard demands that precision and scale fields be
non-null all the time for those data types where they make sense
(this is encoded in the CHECK CONSTRAINTs that are declared for the
Robert Haas robertmh...@gmail.com writes:
Basically, I'm trying to figure out what we're going to recommend to
someone who gets bitten by whatever remaining corner case still exists
after your recent patch, and I admit I'm not real clear on what that
is.
If anyone actually shows up with a
On Sun, Jun 7, 2009 at 11:50 PM, Bruce Momjianbr...@momjian.us wrote:
Stefan Kaltenbrunner wrote:
Josh Berkus wrote:
On 6/7/09 10:56 AM, Robert Haas wrote:
OK, that's more or less what I thought, and what I intended to convey
upthread. As far as core Postgres is concerned this is a new
34 matches
Mail list logo
