On Fri, Jul 30, 2010 at 12:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
We had a report of the above error from a pgAdmin user testing
1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
as a superuser:
SELECT pg_get_expr(proargdefaults,
Hello
2010/7/29 Erik Rijkers e...@xs4all.nl:
On Thu, July 29, 2010 22:43, Erik Rijkers wrote:
Hi Pavel,
In xfunc.sgml, I came across a function example (for use of VARIADIC in
polymorphic functions),
where the function name is concat(): (in the manual: 35.4.10. Polymorphic
SQL
2010/7/29 Josh Berkus j...@agliodbs.com:
Or maybe checking against the source code and its documentation, if any.
No, not really. What you really want to know is: what's the real
planner overhead of having dozens/hundreds of partial indexes? What's
the write overhead? There's no way you
On Fri, Jul 30, 2010 at 11:24 AM, Vincenzo Romano
vincenzo.rom...@notorand.it wrote:
At a first glance it seems that for inheritance some bottleneck is
hindering a full exploit for table partitioning.
There have been lengthy discussions of how to implement partitioning
to fix these precise
On 24/07/10 15:20, Adriano Lange wrote:
Hi,
Hi!
I'd like to release the last version of my experimental join order
algorithm (TwoPO - Two Phase Optimization [1]):
http://git.c3sl.ufpr.br/gitweb?p=lbd/ljqo.git;a=summary
This algorithm is not production-ready, but an experimental set of
On Fri, Jul 30, 2010 at 1:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
But, looking at it a bit more carefully, isn't the maximum-size logic
for numeric rather bogus?
Perhaps, but I think you're confused on at least one point.
numeric(2,1) has to be
2010/7/30 Greg Stark gsst...@mit.edu:
On Fri, Jul 30, 2010 at 11:24 AM, Vincenzo Romano
vincenzo.rom...@notorand.it wrote:
At a first glance it seems that for inheritance some bottleneck is
hindering a full exploit for table partitioning.
There have been lengthy discussions of how to
Hi Pavel,
Thanks for taking the time to review my patch. Attached is a new version
addressing your concerns.
On 29/07/10 14:21, Pavel Stehule wrote:
I have a few issues:
* broken regress test (fedora 13 - xmllint: using libxml version 20707)
postgres=# SELECT xml_is_well_formed('pg:foo
Hello
2010/7/30 Mike Fowler m...@mlfowler.com:
Hi Pavel,
Thanks for taking the time to review my patch. Attached is a new version
addressing your concerns.
On 29/07/10 14:21, Pavel Stehule wrote:
I have a few issues:
* broken regress test (fedora 13 - xmllint: using libxml version 20707)
I think that queries like this:
select * from test where val - 500 1 order by val - 500;
can also be optimized using knngist. In case of btree_gist this query can be
easily rewritten:
select * from test where val 499 and val 501 order by val - 500;
But, in pg_trgm it makes it possible to
On Mon, Jul 26, 2010 at 8:48 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 26, 2010 at 3:49 PM, Merlin Moncure mmonc...@gmail.com wrote:
concat() is not a variadic text function. it is variadic any that
happens to do text coercion (not casting) inside the function. The
the
Dave Page dp...@pgadmin.org writes:
On Fri, Jul 30, 2010 at 12:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I've applied a (rather hurried) patch for this for 9.0beta4.
Thanks. Bruce seemed to think it affected 8.4.4 as well - would that
be the case, or is it something else?
He's mistaken. The
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 30, 2010 at 1:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Perhaps, but I think you're confused on at least one point.
numeric(2,1) has to be able to hold 2 decimal digits, not 2
NumericDigits (which'd actually be 8 decimal digits given
the
On Thu, Jul 29, 2010 at 6:57 AM, Henk Enting h.d.ent...@mgrid.net wrote:
We ran into a problem on 9.0beta3 with check constraints using table
inheritance in a multi-level hierarchy with multiple inheritance.
A test script is provided below and a proposed patch is attached to this
email.
Robert Haas robertmh...@gmail.com writes:
On Thu, Jul 29, 2010 at 6:57 AM, Henk Enting h.d.ent...@mgrid.net wrote:
We ran into a problem on 9.0beta3 with check constraints using table
inheritance in a multi-level hierarchy with multiple inheritance.
Thanks for the report. This bug also
On Fri, Jul 30, 2010 at 10:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jul 29, 2010 at 6:57 AM, Henk Enting h.d.ent...@mgrid.net wrote:
We ran into a problem on 9.0beta3 with check constraints using table
inheritance in a multi-level hierarchy
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 30, 2010 at 10:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The original design idea was that coninhcount/conislocal would act
exactly like attinhcount/attislocal do for multiply-inherited columns.
Where did we fail to copy that logic?
We
On Fri, Jul 30, 2010 at 10:23 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 30, 2010 at 10:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The original design idea was that coninhcount/conislocal would act
exactly like attinhcount/attislocal do for
The Thursday 29 July 2010 13:55:38, Boszormenyi Zoltan wrote :
I fixed this by adding CheckLockTimeout() function that works like
CheckStatementTimeout() and ensuring that the same start time is
used for both deadlock_timeout and lock_timeout if both are active.
The preference of errors if
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 30, 2010 at 10:23 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Uh, full stop there. If you think that the multiply-inherited column
logic is wrong, it's you that is mistaken --- or at least you're going
to have to do a lot more than just assert
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Since the output in the previous email apparently wasn't sufficient
for you to understand what the problem is, here it is in more detail.
...
Adding a column to the toplevel parent of the inheritance hierarchy
and then dropping it again
On Fri, Jul 30, 2010 at 10:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 30, 2010 at 10:23 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Uh, full stop there. If you think that the multiply-inherited column
logic is wrong, it's you that is mistaken
Yeb Havinga yebhavi...@gmail.com writes:
Regard the following lattice (direction from top to bottom):
1
|\
2 3
\|\
4 5
\|
6
When adding a constraint to 1, the proper coninhcount for that
constraint on relation 6 is 2. But the code currently counts to 3, since
6 is reached
On Fri, Jul 30, 2010 at 11:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeb Havinga yebhavi...@gmail.com writes:
Regard the following lattice (direction from top to bottom):
1
|\
2 3
\|\
4 5
\|
6
When adding a constraint to 1, the proper coninhcount for that
constraint on
Boxuan Zhai wrote:
I create a clean patch file (no debug clauses). See the attachment.
Some general coding feedback for you on this.
It's not obvious to people who might want to try this out what exactly
they are supposed to do. Particularly for complicated patches like
this, where only a
On Fri, Jul 30, 2010 at 11:35 AM, Robert Haas robertmh...@gmail.com wrote:
In the case of coninhcount, I believe that the fix actually is quite
simple, although of course it's possible that I'm missing something.
Currently, ATAddConstraint() first calls AddRelationNewConstraints()
to add the
On Fri, Jul 30, 2010 at 12:21 PM, Greg Smith g...@2ndquadrant.com wrote:
If you had those done for this patch, I
wouldn't have to ask for code examples; I could just look at the source to
the regression output and see how to use it against the standard database
the regression samples create,
On Friday 30 July 2010 18:21:49 Greg Smith wrote:
-break;
+break;
This happened because you added two invisible tabs to the end of this
line. This makes the patch larger for no good reason and tends to
If you want to remove changes like this using:
git
OK, here's a review, as much as I was able to do it without
understanding deeply how GIN works.
The patch is context, applies cleanly to HEAD, compiles without warnings
and passes regression tests.
Using the script from
http://archives.postgresql.org/pgsql-performance/2009-10/msg00393.php I
On Fri, Jul 30, 2010 at 1:19 PM, Jan Urbański wulc...@wulczer.org wrote:
The patch has lots of statements like if ( GinPageIsLeaf(page) ), that is
with extra space between the outer parenthesis and the condition, which
AFAIK is not the project style. I guess pgindent fixes that, so it's no big
Robert Haas robertmh...@gmail.com writes:
Maybe something like this,
obviously with a suitable comment which I haven't written yet:
numeric_digits = (precision + 6) / 4;
return (numeric_digits * sizeof(int16)) + NUMERIC_HDRSZ;
This is OK for the base-10K case, but there's still
[ forgot to answer this part ]
Robert Haas robertmh...@gmail.com writes:
Another question here is whether we should just fix this in CVS HEAD,
or whether there's any reason to back-patch it.
Agreed, fixing it in HEAD seems sufficient.
regards, tom lane
--
Sent via
Is there anyone who knows whether those algorithms are linear or not?
Read the code? It's really very accessible, and there's lots and lots
of comments. While the person who wrote the code is around, isn't it
better to see the real implementation?
--
--
Robert Haas wrote:
It seems to me that it should only recurse to its children
if the constraint was really added, rather than merged into an
existing constraint, because if it was merged into an existing
constraint, then the children already have it.
Yes. (then the children already have it -
2010/7/30 Josh Berkus j...@agliodbs.com:
Is there anyone who knows whether those algorithms are linear or not?
Read the code? It's really very accessible, and there's lots and lots
of comments. While the person who wrote the code is around, isn't it
better to see the real implementation?
Yeb Havinga wrote:
Robert Haas wrote:
This still leaves open the question of what to do about the similar
case involving attributes:
That problem looks significantly more difficult to solve, though.
I'm looking at ATPrepAddColumn right now, where there is actually some
comments about
Vincenzo Romano wrote:
By using PREPARE I run the query planned sooner and I should use
the plan with the later execution.
You can bet that some of the PREPAREd query variables will
pertain to either the child table's CHECK contraints (for table partitions)
or to the partial index's WHERE
On Fri, Jul 30, 2010 at 3:50 PM, Vincenzo Romano
vincenzo.rom...@notorand.it wrote:
2010/7/30 Josh Berkus j...@agliodbs.com:
Is there anyone who knows whether those algorithms are linear or not?
Read the code? It's really very accessible, and there's lots and lots
of comments. While the
On Fri, Jul 30, 2010 at 10:22, Robert Haas robertmh...@gmail.com wrote:
OK, it looks like level_2_parent is actually irrelevant to this issue.
So here's a slightly simplified test case:
DROP SCHEMA IF EXISTS test_inheritance CASCADE;
CREATE SCHEMA test_inheritance;
SET search_path TO
On Fri, Jul 30, 2010 at 9:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 30, 2010 at 1:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Perhaps, but I think you're confused on at least one point.
numeric(2,1) has to be able to hold 2 decimal digits,
Here's a second version of the main patch, in which I have attempted
to respond to Tom's concerns/suggestions.
(There is still a small, side issue with numeric_maximum_size() which
I plan to fix, but this patch is the good stuff.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The
Excerpts from Boszormenyi Zoltan's message of jue jul 29 07:55:38 -0400 2010:
Hi,
Marc Cousin írta:
Hi, I've been reviewing this patch for the last few days. Here it is :
...
* Are there dangers?
As it is a guc, it could be set globally, is that a danger ?
I haven't added
On Fri, Jul 30, 2010 at 2:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Maybe something like this,
obviously with a suitable comment which I haven't written yet:
numeric_digits = (precision + 6) / 4;
return (numeric_digits * sizeof(int16))
I've been poking at the FTS problem example recently submitted by
Artur Dabrowski. It contains an index declared like so:
CREATE INDEX idx_keywords_ger ON search_tab
USING gin (to_tsvector('german'::regconfig, keywords));
which can be queried like so
select * from search_tab where
Another misbehavior that I noted while playing with Artur's example is
that, while GIN index build seems to adhere pretty well to whatever
maintenance_work_mem limit you give it in 8.4, it blows right by that
limit in 9.0 and HEAD --- I observed it happily eating something north
of 128MB with a
45 matches
Mail list logo
