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 mai
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
to_
On Fri, Jul 30, 2010 at 2:08 PM, Tom Lane wrote:
> Robert Haas 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 O
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 ?
> >
>
>
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 Ente
On Fri, Jul 30, 2010 at 10:22, Robert Haas 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 test_inheritance;
>
>
On Fri, Jul 30, 2010 at 9:16 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 30, 2010 at 1:13 AM, Tom Lane 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 deci
On Fri, Jul 30, 2010 at 3:50 PM, Vincenzo Romano
wrote:
> 2010/7/30 Josh Berkus :
>>
>>> 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
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 conditi
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 gettin
2010/7/30 Josh Berkus :
>
>> 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?
If the prog
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 -> alr
> 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?
--
-- Jos
[ forgot to answer this part ]
Robert Haas 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 pgsql-hackers mailing
Robert Haas 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 code in there
for
On Fri, Jul 30, 2010 at 1:19 PM, Jan Urbański 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
> deal.
It's bet
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 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
On Fri, Jul 30, 2010 at 12:21 PM, Greg Smith 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, and then execute a
On Fri, Jul 30, 2010 at 11:35 AM, Robert Haas 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 constraint, or poss
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 s
On Fri, Jul 30, 2010 at 11:39 AM, Tom Lane wrote:
> Yeb Havinga 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
Yeb Havinga 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 by paths 1
On Fri, Jul 30, 2010 at 10:46 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 30, 2010 at 10:23 AM, Tom Lane 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 lo
Tom Lane wrote:
Robert Haas 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 shouldn't leave a left
Robert Haas writes:
> On Fri, Jul 30, 2010 at 10:23 AM, Tom Lane 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 that you don't like it.
>> We spe
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
On Fri, Jul 30, 2010 at 10:23 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 30, 2010 at 10:11 AM, Tom Lane 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
Robert Haas writes:
> On Fri, Jul 30, 2010 at 10:11 AM, Tom Lane 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 didn't. That logic is broken, too
On Fri, Jul 30, 2010 at 10:11 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jul 29, 2010 at 6:57 AM, Henk Enting 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
Robert Haas writes:
> On Thu, Jul 29, 2010 at 6:57 AM, Henk Enting 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 appears to exist in 8.4; I'm not
> sure y
On Thu, Jul 29, 2010 at 6:57 AM, Henk Enting 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.
Thanks for the repor
Robert Haas writes:
> On Fri, Jul 30, 2010 at 1:13 AM, Tom Lane 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 current code).
> I get that. T
Dave Page writes:
> On Fri, Jul 30, 2010 at 12:17 AM, Tom Lane 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 bug is in all the branches, bu
On Mon, Jul 26, 2010 at 8:48 PM, Robert Haas wrote:
> On Mon, Jul 26, 2010 at 3:49 PM, Merlin Moncure 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 assumption that concat is casting intern
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 t
Hello
2010/7/30 Mike Fowler :
> 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)
ok -
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('http://postg
2010/7/30 Greg Stark :
> On Fri, Jul 30, 2010 at 11:24 AM, Vincenzo Romano
> 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 prec
On Fri, Jul 30, 2010 at 1:13 AM, Tom Lane wrote:
> Robert Haas 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 able to hold 2 decimal digits, not
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
idea
On Fri, Jul 30, 2010 at 11:24 AM, Vincenzo Romano
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 problems, yes.
> Is there an
2010/7/29 Josh Berkus :
>
>> 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 can derive t
Hello
2010/7/29 Erik Rijkers :
> 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 Functions).
On Fri, Jul 30, 2010 at 12:17 AM, Tom Lane wrote:
> Dave Page 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, 'pg_catalog.pg_class'::regcl
45 matches
Mail list logo
