Pavel Stehule wrote:
2009/2/17 Josh Berkus j...@agliodbs.com:
All,
I thought we'd agreed to compromise on having SE without row-level in
8.4,
and working on SE with row-level in 8.5. Why are we revisiting this
argument? 8.4 is *already* late; arguing further about the terms of SE
simply
I would like to add a --freeze parameter to vacuumdb for use by the
binary upgrade utility, and for symmetry with the existing VACUUM
options; patch attached.
Exactly what do you think the upgrade utility is going to do with it?
Surely not a database-wide VACUUM FREEZE, if we are
On Tue, 2009-02-17 at 18:52 -0500, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I would like to add a --freeze parameter to vacuumdb for use by the
binary upgrade utility, and for symmetry with the existing VACUUM
options; patch attached.
Exactly
Kris Jurka wrote:
Thomas Hallgren wrote:
Kris Jurka wrote:
3) By value: pljava does not correctly handle passed by value types
correctly, allowing access to random memory.
This is simply not true. There's no way a Java developer can access
random memory through PL/Java.
No, the point is
Alvaro Herrera wrote:
Peter Eisentraut wrote:
Log Message:
---
Redefine _() to dgettext() instead of gettext() so that it uses the plpgsql
text domain, instead of the postgres one (or whatever the default may be).
Hmm, so is this needed on all other PLs too?
In principle yes. Or
Bruce Momjian wrote:
The attached patch adds to pg_dumpall --binary-upgrade by restoring
information about frozen xids for relations and databases. I think this
is the last patch I need to complete my TODO items for the pg_migrator
binary upgrade utility.
Applied.
--
Bruce Momjian
Bruce Momjian wrote:
I would like to add a --freeze parameter to vacuumdb for use by the
binary upgrade utility, and for symmetry with the existing VACUUM
options; patch attached.
I could also accomplish with with PGOPTIONs but this seem like a cleaner
solution.
Applied.
--
Bruce
Zeugswetter Andreas OSB sIT wrote:
I would like to add a --freeze parameter to vacuumdb for use by the
binary upgrade utility, and for symmetry with the existing VACUUM
options; patch attached.
Exactly what do you think the upgrade utility is going to do with it?
Surely
On Mon, 2009-02-09 at 17:13 +0200, Heikki Linnakangas wrote:
Attached is an updated patch that does that, and I've fixed all the
other outstanding issues I listed earlier as well. Now I'm feeling
again that this is in pretty good shape.
UpdateMinRecoveryPoint() issues a DEBUG2 message even
Simon Riggs wrote:
On Mon, 2009-02-09 at 17:13 +0200, Heikki Linnakangas wrote:
Attached is an updated patch that does that, and I've fixed all the
other outstanding issues I listed earlier as well. Now I'm feeling
again that this is in pretty good shape.
UpdateMinRecoveryPoint() issues a
On Wed, 2009-02-18 at 14:26 +0200, Heikki Linnakangas wrote:
The outer if should ensure that it isn't printed repeatedly on an idle
system.
Regrettably not.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list
On Wed, Feb 18, 2009 at 1:34 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I'm interested to know whether anyone else shares my belief that
nested loops are the cause of most really bad plans. What usually
happens to me is that the planner develops some
I have completed all the outstanding pg_migratory TODO items.
I still have more work to do in cleanup and testing, but if people want
to look at my progress, now is a good time.
You can download the current CVS here:
http://pgfoundry.org/scm/?group_id=1000235
and you can subscribe to
You've moved fast on this!
#ifdef NOT_USED
/* XXX do we need this at all? */
/*
* Assuming OIDs are only used in system tables, there is no need
to
* restore the OID counter because we have not transfered any OIDs
* from the old
Pavel Stehule wrote:
2009/2/16 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
Next sample of parser hook using:
attachment contains module that transform every empty string to null.
I am not sure, if this behave is exactly compatible with Oracle,
Surely a parser
Robert Haas robertmh...@gmail.com writes:
/* XXX do we need this at all? */
/*
* Assuming OIDs are only used in system tables, there is no need to
* restore the OID counter because we have not transfered any OIDs
* from the old system.
*/
It's certainly not impossible for
On Wed, Feb 18, 2009 at 01:34:25AM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I'm interested to know whether anyone else shares my belief that
nested loops are the cause of most really bad plans. What usually
happens to me is that the planner develops some unwarranted
Bruce Momjian wrote:
I have completed all the outstanding pg_migratory TODO items.
I still have more work to do in cleanup and testing, but if people want
to look at my progress, now is a good time.
Hmm, don't you need to change the Xid counter (pg_resetxlog) if you're
going to mess with
Andrew Chernow wrote:
Maybe better, have it return a zero/nonzero error code; where one of the
possibilities for failure is you passed a bit I didn't understand.
Why not just return those bit(s) instead of an arbitrary code? How about:
-1 = error (if it ever does anything that can fail)
Peter Eisentraut pete...@gmx.net writes:
I'd be quite interested to support some kind of hook to deal with this
Oracle null issue. It would be a great help for porting projects.
However, doing this properly is probably more complex and needs further
thought. I'd suggest writing a type of
Greg Stark wrote:
On Mon, Feb 16, 2009 at 4:14 PM, Robert Haas robertmh...@gmail.com wrote:
I'm not sure I understand what you mean by that. I expect that if I
deny a particular user access to SELECT from a particular table the
system will throw a permissions error if that user later enters
Folks,
Perhaps I've misunderstood this, but in PostgreSQL 8.3.5, I get
disparate results from ~ and SIMILAR TO. For example:
This gives an unexpected result:
davidfet...@davidfetter=# SELECT 'abc' SIMILAR TO '^[a]';
?column?
--
f
(1 row)
This one is what I expected.
Tom Lane t...@sss.pgh.pa.us writes:
No, but this would just be the same situation that prevails after
OID-counter wraparound, so I don't see a compelling need for us to
change the OID counter in the new DB. If the user has done the Proper
Things (ie, made unique indexes on his OIDs) then it
David Fetter wrote:
Folks,
Perhaps I've misunderstood this, but in PostgreSQL 8.3.5, I get
disparate results from ~ and SIMILAR TO. For example:
Did you read the docs? ^ is not an anchor.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL
David Fetter wrote:
Folks,
Perhaps I've misunderstood this, but in PostgreSQL 8.3.5, I get
disparate results from ~ and SIMILAR TO. For example:
This gives an unexpected result:
davidfet...@davidfetter=# SELECT 'abc' SIMILAR TO '^[a]';
?column?
--
f
(1 row)
This one is what I
Gregory Stark st...@enterprisedb.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
No, but this would just be the same situation that prevails after
OID-counter wraparound, so I don't see a compelling need for us to
change the OID counter in the new DB. If the user has done the Proper
Things
If the planning was done with some sort of interval then you'd be
able to encode information about how well your stats characterized the
underlying data. Traditionally awkward things like amount of cache
would serve to drop the lower bound, but not alter the upper. The
planner then
Simon Riggs wrote:
On Wed, 2009-02-18 at 14:26 +0200, Heikki Linnakangas wrote:
The outer if should ensure that it isn't printed repeatedly on an idle
system.
Regrettably not.
Ok, committed. I fixed that and some comment changes. I also renamed
IsRecoveryProcessingMode() to
Tom Lane t...@sss.pgh.pa.us writes:
Gregory Stark st...@enterprisedb.com writes:
Also I wonder about the performance of skipping over thousands or even
millions of OIDs for something like a toast table.
I think that argument is a red herring. In the first place, it's
unlikely that there'd
On Wed, 2009-02-18 at 18:01 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Wed, 2009-02-18 at 14:26 +0200, Heikki Linnakangas wrote:
The outer if should ensure that it isn't printed repeatedly on an idle
system.
Regrettably not.
Ok, committed.
Cool.
I fixed that
Adriano Lange adri...@c3sl.ufpr.br writes:
Hi,
I'm interested in data representation and debug of optimizer routines. Thus,
I've changed the debug functions of allpaths.c to make a graphviz-like output
of RelOptInfo structure.
Any idea about this?
Is there some project or improvement like
Hi everyone,
I want to try to add a multi calendar system for pgsql. I want to know if it
will be accepted as a patch to pgsql?
More details:
Multi calendar systems are useful for several languages and countries using
different calendar: Hijri, Persian, Hebrew, etc.
For implementation I think it
On Wednesday 18 February 2009 10:47:25 Tom Lane wrote:
Gregory Stark st...@enterprisedb.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
No, but this would just be the same situation that prevails after
OID-counter wraparound, so I don't see a compelling need for us to
change the OID
Mohsen Alimomeni m.alimom...@gmail.com writes:
I want to try to add a multi calendar system for pgsql. I want to know if it
will be accepted as a patch to pgsql?
There's probably about zero chance of accepting such a thing into core,
but maybe you could do it as an add-on (pgfoundry project).
Robert Haas robertmh...@gmail.com writes:
Yeah, I thought about this too, but it seems like overkill for the
problem at hand, and as you say it's not clear you'd get any benefit
out of the upper bound anyway. I was thinking of something simpler:
instead of directly multiplying 0.005 into the
I want to try to add a multi calendar system for pgsql. I want to know if it
will be accepted as a patch to pgsql?
More details:
Multi calendar systems are useful for several languages and countries using
different calendar: Hijri, Persian, Hebrew,
etc.
For implementation I think it is
On Wed, Feb 18, 2009 at 11:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah, I thought about this too, but it seems like overkill for the
problem at hand, and as you say it's not clear you'd get any benefit
out of the upper bound anyway. I was thinking
Alvaro Herrera wrote:
Bruce Momjian wrote:
I have completed all the outstanding pg_migratory TODO items.
I still have more work to do in cleanup and testing, but if people want
to look at my progress, now is a good time.
Hmm, don't you need to change the Xid counter (pg_resetxlog) if
Robert Treat wrote:
On Wednesday 18 February 2009 10:47:25 Tom Lane wrote:
Gregory Stark st...@enterprisedb.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
No, but this would just be the same situation that prevails after
OID-counter wraparound, so I don't see a compelling need for us
On Wed, Feb 18, 2009 at 10:22 AM, Adriano Lange adri...@c3sl.ufpr.br wrote:
Hi,
I'm interested in data representation and debug of optimizer routines. Thus,
I've changed the debug functions of allpaths.c to make a graphviz-like
output of RelOptInfo structure.
Any idea about this?
Is there
On Wed, 2009-02-18 at 07:50 -0500, Robert Haas wrote:
(Now it appears that Josh is having problems that are caused by
overestimating the cost of a page fetch, perhaps due to caching
effects. Those are discussed upthread, and I'm still interested to
see whether we can arrive at any sort of
On Wed, Feb 18, 2009 at 07:50:31PM +0330, Mohsen Alimomeni wrote:
Multi calendar systems are useful for several languages and countries using
different calendar: Hijri, Persian, Hebrew, etc.
When would the differences between these calenders actually show
up? I can only think of it affecting
Gregory Stark st...@enterprisedb.com writes:
Adriano Lange adri...@c3sl.ufpr.br writes:
I've changed the debug functions of allpaths.c to make a graphviz-like output
of RelOptInfo structure.
However I have to say this graph you've generated is amazingly hard to
decipher :) It took me a while
hi,
i've been testing new -m option of pg_restore with great pleasure.
first, let me thank the developpers, it cut restoring time by half.
is it normal that -m doesn't cope well with -C?
createdb db
pg_restore -m 4 -d db db.dmp
works like a charm while
pg_restore -C -m 4 -d template1 db.dmp
Bruce Momjian br...@momjian.us writes:
One compromise is outputting the pg_resetxlog command to the terminal,
and suggesting they run it only if they need to.
Er, what? pg_resetxlog is certainly not optional in this process.
regards, tom lane
--
Sent via
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
One compromise is outputting the pg_resetxlog command to the terminal,
and suggesting they run it only if they need to.
Er, what? pg_resetxlog is certainly not optional in this process.
The oid setting part is.
--
Bruce Momjian
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Er, what? pg_resetxlog is certainly not optional in this process.
The oid setting part is.
Yeah, but if you have to run it anyway it certainly isn't going to be
any more work to make it set the OID counter too.
o...@pyrenet.fr writes:
pg_restore -C -m 4 -d template1 db.dmp
gives numerous errors, mostly no such relation at index creation time.
You sure you don't get exactly the same without -m?
regards, tom lane
--
Sent via pgsql-hackers mailing list
m.alimom...@gmail.com (Mohsen Alimomeni) writes:
I want to try to add a multi calendar system for pgsql. I want to
know if it will be accepted as a patch to pgsql?
I would expect there to be nearly zero chance of such, at least in the
form of a change to how dates are stored.
As long as there
Tom Lane wrote:
We don't, however, expect that all platforms will produce minus zero, so
we need to adjust the one affected regression test to allow both results.
Do we know if and what platforms wouldn't produce minus zero? It would
be interesting to not have the alternative expected output
Robert Haas wrote:
experience, most bad plans are caused by bad selectivity estimates,
and the #1 source of bad selectivity estimates is selectivity
estimates for unknown expressions.
ISTM unknown expressions should be modeled as a range of
values rather than one single arbitrary value.
For
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
We don't, however, expect that all platforms will produce minus zero, so
we need to adjust the one affected regression test to allow both results.
Do we know if and what platforms wouldn't produce minus zero? It
On Wed, Feb 18, 2009 at 2:46 PM, Ron Mayer
rm...@cheapcomplexdevices.com wrote:
Robert Haas wrote:
experience, most bad plans are caused by bad selectivity estimates,
and the #1 source of bad selectivity estimates is selectivity
estimates for unknown expressions.
ISTM unknown expressions
Robert Haas robertmh...@gmail.com writes:
... At any rate, we'd need to save quite
a bit to pay for carting around best and worst case costs for every
plan we consider.
Another problem with this is it doesn't really do anything to solve the
problem we were just discussing, namely having an
hei...@postgresql.org (Heikki Linnakangas) writes:
Log Message:
---
Start background writer during archive recovery.
Might that have anything to do with this?
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dungbeetledt=2009-02-18%2019:44:01
regards, tom
On Wed, Feb 18, 2009 at 3:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
... At any rate, we'd need to save quite
a bit to pay for carting around best and worst case costs for every
plan we consider.
Another problem with this is it doesn't really do
On Wed, 2009-02-18 at 15:43 -0500, Tom Lane wrote:
hei...@postgresql.org (Heikki Linnakangas) writes:
Log Message:
---
Start background writer during archive recovery.
Might that have anything to do with this?
On Wed, 2009-02-18 at 21:28 +, Simon Riggs wrote:
On Wed, 2009-02-18 at 15:43 -0500, Tom Lane wrote:
hei...@postgresql.org (Heikki Linnakangas) writes:
Log Message:
---
Start background writer during archive recovery.
Might that have anything to do with this?
On Wed, 2009-02-18 at 15:32 -0500, Tom Lane wrote:
An idea that I think has been mentioned before is to try to identify
cases where we can *prove* there is at most one row emitted by a
sub-path (eg, because of a unique index, DISTINCT subplan, etc). Then
we could penalize nestloops with
Simon Riggs si...@2ndquadrant.com writes:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dungbeetledt=2009-02-18%2019:44:01
More likely to be an uncommon race condition, rather than a error
specific to dungbeetle.
I agree, that's what it looks like, especially since I couldn't
duplicate it
Simon Riggs si...@2ndquadrant.com writes:
On Wed, 2009-02-18 at 15:32 -0500, Tom Lane wrote:
An idea that I think has been mentioned before is to try to identify
cases where we can *prove* there is at most one row emitted by a
sub-path (eg, because of a unique index, DISTINCT subplan, etc).
Tom Lane escreveu:
Gregory Stark st...@enterprisedb.com writes:
Adriano Lange adri...@c3sl.ufpr.br writes:
I've changed the debug functions of allpaths.c to make a graphviz-like output
of RelOptInfo structure.
However I have to say this graph you've generated is amazingly hard to
decipher
Robert Haas escreveu:
That is pretty cool.
It would help a lot to label the baserels with their names.
You might also want to move the RestrictInfo out of line so that it's
easier to see where the inner and outer joinpath arrows are going.
Humm. Maybe this is not easy to do in dot command
On Tue, Feb 17, 2009 at 2:28 PM, Teodor Sigaev teo...@sigaev.ru wrote:
Hi there,
we present two variants of GIN fast insert patch, since we're not sure
what is a the best solution:
v0.28.1
- remove disable cost in gincostestimate
- per
On Wed, Jan 7, 2009 at 9:14 AM, Joshua Tolley eggyk...@gmail.com wrote:
On Tue, Jan 06, 2009 at 11:49:57PM -0500, Robert Haas wrote:
Josh / eggyknap -
Can you rerun your performance tests with this version of the patch?
...Robert
Will do, as soon as I can.
Josh,
Have you been able to do
At this point, we await further feedback on what is necessary to get
this patch accepted. We would also like to thank Josh and Robert again
for their review time.
I think what we need here is some very simple testing to demonstrate
that this patch demonstrates a speed-up even when the inner
Simon Riggs wrote:
More likely to be an uncommon race condition, rather than a error
specific to dungbeetle. If startup process death is slow, this could
happen, though hasn't occurred in other tests.
True, the startup process can live for a short while concurrently with
bgwriter, walwriter
2009/2/18 Peter Eisentraut pete...@gmx.net:
Pavel Stehule wrote:
2009/2/16 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
Next sample of parser hook using:
attachment contains module that transform every empty string to null.
I am not sure, if this behave is
68 matches
Mail list logo
