I don't need to add new node types or add any syntax; it is the output that
I'm concerned with. What I want is a way to print a tree according to some
pretty strict rules. For example, I want a special syntax for function RTEs
and I don't want the v::type notation to be output (the flag to turn it
Tom Lane wrote:
Hmm, does this proposal require adding a test of well-formed-ness to
a code path that doesn't currently have one? If so, is that likely
to contribute any noticeable slowdown?
I can't offhand see an objection to this other than possible performance
impact.
James Pye wrote:
On Feb 26, 2009, at 5:41 PM, Andrew Dunstan wrote:
http://www.exslt.org/exsl/functions/node-set/index.html
A node-set isn't a document.
yes.. :)
I guess what I'm saying is that if:
tinman=# SELECT XML'';
xml
--
(1 row)
is considered to be valid per *S
Hackers,
Is there any reason we don't have an pg_get_operatordef() in 8.4, other
than nobody writing the code? I don't see any issues in archives ...
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/m
On Feb 26, 2009, at 5:41 PM, Andrew Dunstan wrote:
http://www.exslt.org/exsl/functions/node-set/index.html
A node-set isn't a document.
yes.. :)
I guess what I'm saying is that if:
tinman=# SELECT XML'';
xml
--
(1 row)
is considered to be valid per *SQL-XML*, then it sho
If Kerberos V5 is not installed on a Windows platform, the following
error dialog is returned upon attempted installation:
Posgres.exe - Unable to Locate Component
This application has failed to start because krb5_32.dll was not found.
Re-installing the application may fix this problem.
[OK]
--
Adriano Lange wrote:
> The patch attached is an implementation for graph generation of data
> structures in postgres. The file debuggraph.c is a simple library that
> generate graphs in the format supported by graphviz.
It's interesting, but I don't think it is suitable for a core feature.
Cou
Bruce Momjian wrote:
KaiGai Kohei wrote:
Bruce Momjian wrote:
KaiGai Kohei wrote:
The series of SE-PostgreSQL patches for v8.4 were updated:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1608.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1608.patch
James Pye wrote:
On Feb 26, 2009, at 9:37 AM, Peter Eisentraut wrote:
It's not about ill-formed pieces, it is about (well-formed) content
fragments that are not full documents (exactly one root element).
libxml2 doesn't support xpath on content fragments.
exslt:node-set() to the rescue? Or
On Feb 26, 2009, at 9:37 AM, Peter Eisentraut wrote:
It's not about ill-formed pieces, it is about (well-formed) content
fragments that are not full documents (exactly one root element).
libxml2 doesn't support xpath on content fragments.
exslt:node-set() to the rescue? Or is that/equivalent
On Thu, Feb 26, 2009 at 3:54 PM, Andrew Dunstan wrote:
> Robert Haas wrote:
>> But the change you're proposing seems like
>> it could CONCEIVABLY break a working application that counts on
>> PostgreSQL's particular flavor of misbehavior, and therefore it seems
>> questionable to put that into a s
Attached is the doc patch for the recently added probes.
-Robert
Index: doc/src/sgml/monitoring.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/monitoring.sgml,v
retrieving revision 1.63
diff -u -3 -p -r1.63 monitoring.sgml
The patch originally modified the cost function but I removed that
part before we submitted it to be a bit conservative about our
proposed changes. I didn't like that for large plans the statistics
were retrieved and calculated many times when finding the optimal
query plan.
The overhead of the a
Andrew Dunstan writes:
> First, I propose that we abandon this mangling, if, and only if, the xml
> is in fact a well formed XML document. Since the whole point of the
> mangling is to handle situations where the XML is not a well formed
> document, that seems fairly straight-forward. If this c
I wrote:
Second, I propose that, in the remaining cases, where we do mangle the
XML, if the xpath expression does not begin with a '/', instead of
prepending it with '/x/, which can not possibly be correct under any
circumstance, we prepend it with '/x//' which has some possibility of
givi
Robert Haas wrote:
But the change you're proposing seems like
it could CONCEIVABLY break a working application that counts on
PostgreSQL's particular flavor of misbehavior, and therefore it seems
questionable to put that into a stable branch. The fact that the
application perhaps should not ha
On Thu, 2009-02-26 at 15:37 -0500, Robert Haas wrote:
> Mine is very light indeed. But the change you're proposing seems like
> it could CONCEIVABLY break a working application that counts on
> PostgreSQL's particular flavor of misbehavior,
That is what release notes are for.
Joshua D. Drake
On Thu, Feb 26, 2009 at 3:18 PM, Andrew Dunstan wrote:
>> I dunno, aren't XML document fragments sort of a pretty common case?
>
> They are. So what? How does that contradict either of the statements made
> above?
>
> Programmers using libxml2 are used to handling this problem. Why must
> postgres
Robert Haas wrote:
What I have proposed for 8.3 should not break a single case that currently
behaves usefully. If anyone has a counter-example please show it.
What I have proposed for 8.4 possibly would break current "useful" behaviour
(FSVO "useful"), but should be done anyway on correctness
Simon Riggs wrote:
On Thu, 2009-02-26 at 20:38 +0200, Heikki Linnakangas wrote:
I think we should simply remove the signal handler for SIGQUIT from
pg_standby.
If you do this, please make it release dependent so pg_standby behaves
correctly for the release it is being used with.
Hmm, I don'
Dave Gudeman writes:
> I would replace this with a table-driven deparser:
> deparse_table[nodeTag(node)](node, context);
I don't actually see what this is going to buy for you. You didn't
say exactly why ruleutils doesn't work for you, but reading between
the lines suggests that you want
On Thu, 2009-02-26 at 20:38 +0200, Heikki Linnakangas wrote:
> I think we should simply remove the signal handler for SIGQUIT from
> pg_standby.
If you do this, please make it release dependent so pg_standby behaves
correctly for the release it is being used with.
--
Simon Riggs ww
Hi,
On Fri, Feb 27, 2009 at 3:38 AM, Heikki Linnakangas
wrote:
> I think the real problem here is that pg_standby traps SIGQUIT. The startup
> process doesn't receive the SIGQUIT because it's in system(), and pg_standby
> doesn't propagate it to the startup process either because it traps it.
Ye
While writing a shared-library extension for Postgres, I needed to output
SQL expressions from trees. The only facility for doing that seems to be the
deparse code in ruleutils.c, which is really intended for outputing rules
and constraints, not for producing general SQL, so it didn't do quite what
Bruce Momjian wrote:
KaiGai Kohei wrote:
The series of SE-PostgreSQL patches for v8.4 were updated:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1608.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1608.patch
[3/5] http://sepgsql.googlecode.com/files/s
> What I have proposed for 8.3 should not break a single case that currently
> behaves usefully. If anyone has a counter-example please show it.
>
> What I have proposed for 8.4 possibly would break current "useful" behaviour
> (FSVO "useful"), but should be done anyway on correctness grounds.
I d
Fujii Masao wrote:
On Fri, Jan 30, 2009 at 7:47 PM, Simon Riggs wrote:
That whole area was something I was leaving until last, since immediate
shutdown doesn't work either, even in HEAD. (Fujii-san and I discussed
this before Christmas, briefly).
This problem remains in current HEAD. I mean,
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
I'm okay with removing this for 8.4, but I think it's too late to
change the behavior of 8.3.
It's never too late to fix a bug.
When the proposed fix involves breaking cases that used to behave
usefully, you n
Andrew Dunstan writes:
> Tom Lane wrote:
>> I'm okay with removing this for 8.4, but I think it's too late to
>> change the behavior of 8.3.
> It's never too late to fix a bug.
When the proposed fix involves breaking cases that used to behave
usefully, you need a much stronger argument than that
Tom Lane wrote:
Andrew Dunstan writes:
I don't think it is our responsibility to remedy the deficiencies of
libxml2, especially if it involves breaking the processing of valid
xpath expressions on well formed XML.
If someone can come up with a correct scheme for handling fragmen
Andrew Dunstan writes:
> I don't think it is our responsibility to remedy the deficiencies of
> libxml2, especially if it involves breaking the processing of valid
> xpath expressions on well formed XML.
> If someone can come up with a correct scheme for handling fragments, I'm
> all ears, but
On Thu, Feb 26, 2009 at 12:23 PM, Greg Sabino Mullane wrote:
>> This one is very basic, it just shows the child tables of a specific
>> table when you type \d in psql :
>
> I'm not so jazzed about this, as I work on systems that have literally
> hundreds of child tables. When I do a \d on the mas
> That seems VERY useful - can you post the other ones (Z1, etc.) so I
> can download them all?
The Z1 data set is posted at:
http://people.ok.ubc.ca/rlawrenc/tpch1g1z.zip
I have not generated Z2, Z3, Z4 for 1G, but I can generate the Z2 and Z3
data sets, and in a hour or two they will be at:
h
> I have posted a pg_dump of the TPCH 1G Z0 data set at:
>
> http://people.ok.ubc.ca/rlawrenc/tpch1g0z.zip
That seems VERY useful - can you post the other ones (Z1, etc.) so I
can download them all?
Thanks,
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> This one is very basic, it just shows the child tables of a specific
> table when you type \d in psql :
I'm not so jazzed about this, as I work on systems that have literally
hundreds of child tables. When I do a \d on the master table, that
Hi,
On Fri, Jan 30, 2009 at 7:47 PM, Simon Riggs wrote:
> That whole area was something I was leaving until last, since immediate
> shutdown doesn't work either, even in HEAD. (Fujii-san and I discussed
> this before Christmas, briefly).
This problem remains in current HEAD. I mean, immediate sh
Peter Eisentraut wrote:
Andrew Dunstan wrote:
For fear of passing an ill formed fragment of xml to the processor,
we strip the xml declaration if any and surround what's left with
'" and '' and prepend '/x' to the supposed xpath. This is just
horrible. It will break for every xpath expressio
> They're automatically generated by the dbgen utility, a link to which
> was originally published somewhere in this thread. That tool creates a
> few text files suitable (with some tweaking) for a COPY command. I've
> got the original files... the .tbz I just made is 1.8 GB :) Anyone
have
> somepl
> From: Tom Lane
> Heikki's got a point here: the planner is aware that hashjoin doesn't
> like skewed distributions, and it assigns extra cost accordingly if it
> can determine that the join key is skewed. (See the "bucketsize"
stuff
> in cost_hashjoin.) If this patch is accepted we'll want to t
On Thu, 2009-02-26 at 11:02 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> >
> > On Wed, 2009-02-25 at 17:50 -0500, Bruce Momjian wrote:
> > > Simon Riggs wrote:
> > > > On Thu, 2009-02-26 at 06:15 +0900, Fujii Masao wrote:
> > > > >
> > > > > Again, I'm not planning to get rid of any exist
On Thu, Feb 26, 2009 at 11:41 AM, Teodor Sigaev wrote:
>> it be? So far we've ruled out using the planner to prevent index
>> scans when the pending list is long (because it's not reliable) and
>> cleaning up the pending list during insert when needed (because it
>> won't work with Hot Standby).
it be? So far we've ruled out using the planner to prevent index
scans when the pending list is long (because it's not reliable) and
cleaning up the pending list during insert when needed (because it
won't work with Hot Standby). We haven't decided what WILL work,
During insert it will work wi
Andrew Dunstan wrote:
For fear of passing an ill formed fragment of xml to the processor, we
strip the xml declaration if any and surround what's left with '" and
'' and prepend '/x' to the supposed xpath. This is just horrible. It
will break for every xpath expression that doesn't begin with a
KaiGai Kohei wrote:
> The series of SE-PostgreSQL patches for v8.4 were updated:
> [1/5] http://sepgsql.googlecode.com/files/sepgsql-core-8.4devel-r1608.patch
> [2/5] http://sepgsql.googlecode.com/files/sepgsql-utils-8.4devel-r1608.patch
> [3/5] http://sepgsql.googlecode.com/files/sepgsql-policy-8.
>>> Bruce Momjian wrote:
> Simon Riggs wrote:
>> On Wed, 2009-02-25 at 17:50 -0500, Bruce Momjian wrote:
>> > Simon Riggs wrote:
>> > > On Thu, 2009-02-26 at 06:15 +0900, Fujii Masao wrote:
>> > > >
>> > > > Again, I'm not planning to get rid of any existing
>> > > > capabilities
>> > >
>> > >
Teodor, can you confirm
* we WAL log the insert into the pending list
* we WAL log the move from the pending list to the main index
Yes, I can and I confirm
* that we maintain the pending list correctly during redo so that it can
be accessed by index scans
Not sure about correct locking in gi
Robert Haas wrote:
> On Thu, Feb 26, 2009 at 3:47 AM, Dave Page wrote:
> >> I think his reply states that. The long and short is, what Tom was
> >> concerned about is true and Heikki has confirmed it. This patch as nice
> >> as it would be to have, isn't ready for prime time. It is time to push
>
Simon Riggs wrote:
>
> On Wed, 2009-02-25 at 17:50 -0500, Bruce Momjian wrote:
> > Simon Riggs wrote:
> > > On Thu, 2009-02-26 at 06:15 +0900, Fujii Masao wrote:
> > > >
> > > > Again, I'm not planning to get rid of any existing capabilities
> > >
> > > Good
> > >
> > > > unless necessary.
>
Heikki's got a point here: the planner is aware that hashjoin doesn't
like skewed distributions, and it assigns extra cost accordingly if it
can determine that the join key is skewed. (See the "bucketsize" stuff
in cost_hashjoin.) If this patch is accepted we'll want to tweak that
code.
Still, t
David Fetter writes:
> On Wed, Feb 25, 2009 at 07:30:30PM -0500, Tom Lane wrote:
>> See the note at the top of that file that all queries are expected
>> to work with server versions back to 7.4.
> Would it be OK to have a different code path for pre-8.4 databases?
I don't really see the point h
On Wed, Feb 25, 2009 at 07:30:30PM -0500, Tom Lane wrote:
> David Fetter writes:
> > Should the patch (and the feature) use WITH RECURSIVE in order to
> > get the entire tree?
>
> See the note at the top of that file that all queries are expected
> to work with server versions back to 7.4.
Would
On Thu, Feb 26, 2009 at 08:22:52AM -0500, Robert Haas wrote:
> On Thu, Feb 26, 2009 at 4:22 AM, Heikki Linnakangas
> wrote:
> > Joshua, in the tests that you've been running, did you have to rig the
> > planner with "enable_mergjoin=off" or similar, to get the queries to use
> > hash joins?
>
> I
On Thu, Feb 26, 2009 at 3:47 AM, Dave Page wrote:
>> I think his reply states that. The long and short is, what Tom was
>> concerned about is true and Heikki has confirmed it. This patch as nice
>> as it would be to have, isn't ready for prime time. It is time to push
>> this patch to 8.5, close u
On Wed, Feb 25, 2009 at 10:24:21PM -0500, Robert Haas wrote:
> I don't think we're really doing this the right way. EXPLAIN ANALYZE
> has a measurable effect on the results, and we probably ought to stop
> the database and drop the VM caches after each query. Are the Z1-Z7
> datasets on line some
Tom Lane wrote:
Andrew Dunstan writes:
For fear of passing an ill formed fragment of xml to the processor, we
strip the xml declaration if any and surround what's left with '" and
'' and prepend '/x' to the supposed xpath. This is just horrible.
I seem to recall having complained a
On Thu, Feb 26, 2009 at 4:22 AM, Heikki Linnakangas
wrote:
> I haven't been following this thread closely, so pardon if this has been
> discussed already.
>
> The patch doesn't seem to change the cost estimates in the planner at all.
> Without that, I'd imagine that the planner rarely chooses a mu
On Thu, 2009-02-26 at 12:19 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2009-02-26 at 11:36 +0200, Heikki Linnakangas wrote:
> >
> >>> You haven't even given a good reason to make these changes.
> >> Simplicity.
> >
> > You used that argument in January to explain why the c
Simon Riggs wrote:
On Thu, 2009-02-26 at 11:36 +0200, Heikki Linnakangas wrote:
You haven't even given a good reason to make these changes.
Simplicity.
You used that argument in January to explain why the coupling should be
reduced and now the same argument to put it back again.
That was i
On Thu, 2009-02-26 at 11:36 +0200, Heikki Linnakangas wrote:
> > You haven't even given a good reason to make these changes.
>
> Simplicity.
You used that argument in January to explain why the coupling should be
reduced and now the same argument to put it back again.
> > We don't have time to
Greg,
>
> Well we won't eliminate any problems unless we actually override the
> effective_cache_size setting by clipping it to shared_buffers. I don't
> really see much of a problem doing that. The only case where that
> would annoy someone was if they're intentionally understating
> effective_ca
Simon Riggs wrote:
On Thu, 2009-02-26 at 10:04 +0200, Heikki Linnakangas wrote:
we keep track of which xids
have already been "reported" in the WAL (similar to what you had in an
earlier version of the patch)
You objected to doing exactly that earlier.
I'm talking about the "xidMarkedInWAL
On Wed, 2009-02-25 at 17:50 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Thu, 2009-02-26 at 06:15 +0900, Fujii Masao wrote:
> > >
> > > Again, I'm not planning to get rid of any existing capabilities
> >
> > Good
> >
> > > unless necessary.
> >
> > That is not a caveat I will acce
I haven't been following this thread closely, so pardon if this has been
discussed already.
The patch doesn't seem to change the cost estimates in the planner at
all. Without that, I'd imagine that the planner rarely chooses a
multi-batch hash join to begin with.
Joshua, in the tests that yo
On Thu, 2009-02-26 at 10:04 +0200, Heikki Linnakangas wrote:
> we keep track of which xids
> have already been "reported" in the WAL (similar to what you had in an
> earlier version of the patch)
You objected to doing exactly that earlier. Why is it OK to do it now
that you are proposing it?
Y
On Thu, Feb 26, 2009 at 7:09 AM, Joshua D. Drake wrote:
> I think his reply states that. The long and short is, what Tom was
> concerned about is true and Heikki has confirmed it. This patch as nice
> as it would be to have, isn't ready for prime time. It is time to push
> this patch to 8.5, clos
Simon Riggs wrote:
On Tue, 2009-02-24 at 21:59 +0200, Heikki Linnakangas wrote:
I think if I had not made those into procs you would have said that they
are so similar it would aid code readability to have them be the same.
And in fact I suggested earlier that we get rid of the unobserved xids
On Thu, Feb 26, 2009 at 1:33 AM, Joshua D. Drake wrote:
>
> On Wed, 2009-02-25 at 17:04 -0800, Josh Berkus wrote:
>
>> Joshua D. Drake wrote:
>>
>> > I would say no. Although I could see an argument for the default
>> > effective_cache_size always being the same size as shared_buffers.
>>
>> That'
Simon Riggs wrote:
On Tue, 2009-02-24 at 21:59 +0200, Heikki Linnakangas wrote:
What benefit would we gain from separating them, especially since we now
have working, tested code?
Simplicity. That matters a lot. Removing the distinction between
unobserved xids and already-observed running trans
68 matches
Mail list logo
