2009/2/18 Peter Eisentraut :
> Pavel Stehule wrote:
>>
>> 2009/2/16 Tom Lane :
>>>
>>> Pavel Stehule 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,
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 a
> 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
On Wed, Jan 7, 2009 at 9:14 AM, Joshua Tolley 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 anythi
On Tue, Feb 17, 2009 at 2:28 PM, Teodor Sigaev 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 http://archives.postgresql.org/message-id/499466d2.4010...@siga
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
Tom Lane escreveu:
Gregory Stark writes:
Adriano Lange 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 to even figure out wha
Simon Riggs 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).
> Proof seems be
Simon Riggs writes:
>>> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dungbeetle&dt=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 on Fedora 9 x86
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
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
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?
>
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dungbe
On Wed, Feb 18, 2009 at 3:32 PM, Tom Lane wrote:
> Robert Haas 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 w
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=dungbeetle&dt=2009-02-18%2019:44:01
regards, tom
Robert Haas 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 intelligent way of
com
On Wed, Feb 18, 2009 at 2:46 PM, Ron Mayer
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 should be modeled as a r
Heikki Linnakangas 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 would
> be interesting to not h
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
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 f
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
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 (pgsql-hackers@postgresq
Bruce Momjian 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.
regards, tom l
Tom Lane wrote:
> Bruce Momjian 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 ht
Bruce Momjian 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 pgsql-hackers mailing list
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
gi
Gregory Stark writes:
> Adriano Lange 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 to even figure out what information
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
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 10:22 AM, Adriano Lange 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 some project
Robert Treat wrote:
> On Wednesday 18 February 2009 10:47:25 Tom Lane wrote:
> > Gregory Stark writes:
> > > Tom Lane 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 co
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_rese
On Wed, Feb 18, 2009 at 11:46 AM, Tom Lane wrote:
> Robert Haas 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
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 better
Robert Haas 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 selectivity every
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?
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).
> For implementation
On Wednesday 18 February 2009 10:47:25 Tom Lane wrote:
> Gregory Stark writes:
> > Tom Lane 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 use
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 i
Adriano Lange 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 this?
Sever
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.
Tom Lane writes:
> Gregory Stark 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 be a huge run of consecutive OIDs
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 RecoveryInPr
> 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 auto
Gregory Stark writes:
> Tom Lane 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 O
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 exp
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 Replica
Tom Lane 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 won't matter.
>
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.
davidfet...@dav
Greg Stark wrote:
On Mon, Feb 16, 2009 at 4:14 PM, Robert Haas 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
"SELECT * FROM ". I don
Peter Eisentraut 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 regression t
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 fai
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
On Wed, Feb 18, 2009 at 01:34:25AM -0500, Tom Lane wrote:
> Robert Haas 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 optimism
> > a
Robert Haas 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 someone to
Pavel Stehule wrote:
2009/2/16 Tom Lane :
Pavel Stehule 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 hook like this would have nothing whatsoever
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
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 th
On Wed, Feb 18, 2009 at 1:34 AM, Tom Lane wrote:
> Robert Haas 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 optimism
>> about the num
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 lis
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 DEB
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 eve
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 wit
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
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
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 cal
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
On Tue, 2009-02-17 at 18:52 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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 wh
> > > 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 FRE
> Pavel Stehule wrote:
>> 2009/2/17 Josh Berkus :
>>> 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
>>>
68 matches
Mail list logo
