>
> It seems odd to require a dummy ELSE clause that does nothing just to
> avoid having an exception thrown, but I'm not sure what else to make
> of the quoted portion of the spec. What do you think it's saying?
>
I thinking so it designed to be protected before processing CASE
statement without
Jaime Casanova writes:
> well actually i get here when translating the plpgsql messages and
> found very strange a message like "case not found", and as a last
> argument (a weak one, i have to admit) i will say that the hint could
> be innecesary if we use the same message the spec is suggesting.
On Sun, Mar 28, 2010 at 12:38 AM, Tom Lane wrote:
> Robert Haas writes:
>
>> It seems odd to require a dummy ELSE clause that does nothing just to
>> avoid having an exception thrown, but I'm not sure what else to make
>> of the quoted portion of the spec. What do you think it's saying?
>
> I co
I wrote:
> [ crude patch ]
Oh, btw, if you try to run the regression test additions in that patch
against CVS HEAD, you'll find out that HEAD actually fails to optimize
the two-levels-of-removable-joins case. Seems like another reason to
press ahead with making the change.
Robert Haas writes:
> On Sat, Mar 27, 2010 at 10:08 PM, Jaime Casanova
> wrote:
>> this is based on General Rules case 1 of chapter 13.6 (case statement)
>> but i don't think that behaviour is the meaning of that Rule. Even if
>> it is, the exception should be: "case not found for case statement"
Robert Haas writes:
> On Sat, Mar 27, 2010 at 4:11 PM, Tom Lane wrote:
>> I'm not seeing how that would occur or would matter, but the worst case
>> answer is to restart the scan of the SpecialJoinInfos from scratch any
>> time you succeed in doing a join removal.
> Well, say you have something
On Sat, Mar 27, 2010 at 10:08 PM, Jaime Casanova
wrote:
> I found something strange (at least for my limited view).
>
> in pl_exec.c:1549 in the function exec_stmt_case() we have this:
>
> """
> /* SQL2003 mandates this error if there was no ELSE clause */
> if (!stmt->have_else)
> er
On Sat, Mar 27, 2010 at 10:08 PM, Jaime Casanova
wrote:
> Hi,
>
[...]
>
> this is based on General Rules case 1 of chapter 13.6 (case statement)
> but i don't think that behaviour is the meaning of that Rule. Even if
> it is, the exception should be: "case not found for case statement"
> and not j
Hi,
I found something strange (at least for my limited view).
in pl_exec.c:1549 in the function exec_stmt_case() we have this:
"""
/* SQL2003 mandates this error if there was no ELSE clause */
if (!stmt->have_else)
ereport(ERROR,
(errcode(ERRCODE_CASE_NOT_FOUND),
Gokulakannan Somasundaram writes:
>The function outDatum doesn't take care of varlena structures which are
> stored externally. Is it the intention??
For its use for debugging purposes, this is a preferable behavior: it
shows you what's actually there. For its use for storing rule trees,
it
On Sat, Mar 27, 2010 at 7:36 PM, Simon Riggs wrote:
> On Sat, 2010-03-27 at 19:15 +, Greg Stark wrote:
> > If we're pruning an index entry to a heap tuple that has been HOT
> > pruned wouldn't the HOT pruning record have already conflicted with
> > any queries that could see it?
>
> Quite pro
Hi,
The function outDatum doesn't take care of varlena structures which are
stored externally. Is it the intention??
Thanks,
Gokul.
>
> Please write it, then test the performance and publish your results,
> with a detailed analysis of whether there is benefit and in which cases
> there is a loss.
>
>
> Thanks. Will do it. Just wanted to know, whether the idea will get
rejected right away / worth trying out.
Thanks,
Gokul.
On 3/27/10 12:11 AM, Gokulakannan Somasundaram wrote:
> I don't think this should involve much code change. But no-one
> interested
We're in the test period for 9.0, so potential 9.1 features are going to
get less attention. If it's a small amount of code, I suggest just
writing the patch and
On 3/27/10 2:23 AM, Peter Eisentraut wrote:
> and earlier discussions of similar nature, here is a patch that
> separates the documentation build and installation into separate
> top-level targets 'make docs' and 'make install-docs', also dependencies
> of 'make world' and 'make install-world'.
Ya
On Sat, Mar 27, 2010 at 4:11 PM, Tom Lane wrote:
>> In particular, if
>> you remove one join, it might make some other join that wasn't
>> previously removable now able to be removed, and it's not exactly
>> clear to me how to make this method cope with that.
>
> I'm not seeing how that would occu
Robert Haas writes:
> On Sat, Mar 27, 2010 at 10:50 AM, Tom Lane wrote:
>> It might be that in
>> practice it has to succeed with the min LHS if it's going to succeed
>> anywhere, but I'm not convinced.
> It's a bit difficult to wrap one's brain around all the cases, but I
> think that the state
On Sat, 2010-03-27 at 19:15 +, Greg Stark wrote:
> On Sat, Mar 27, 2010 at 10:10 AM, Simon Riggs wrote:
> > It appears that in practice many of the index items point to heap items
> > that are LP_DEAD. So for the purposes of accessing a heap tuple's xmin,
> > then we're both right. To the curr
On Fri, Mar 26, 2010 at 10:19 PM, Joseph Adams
wrote:
> One problem with a textual substitution is that implicit variable use
> (e.g. selecting from a view) can't be substituted, at least not
> trivially. As for "sending unnecessary variables with every query",
> my idea was to store those variab
On Sat, Mar 27, 2010 at 10:10 AM, Simon Riggs wrote:
> It appears that in practice many of the index items point to heap items
> that are LP_DEAD. So for the purposes of accessing a heap tuple's xmin,
> then we're both right. To the current purpose the tuple has been
> removed, though you are also
On Sat, Mar 27, 2010 at 10:50 AM, Tom Lane wrote:
> Robert Haas writes:
>> I'm not totally sure about this but I think it's possible to do this
>> without a combinatorial search. Suppose we just iterate over the list
>> of
>> SpecialJoinInfo structures and look for those where jointype is LEFT,
On Sat, 2010-03-27 at 02:23 +0530, Gokulakannan Somasundaram wrote:
>Since we insert a new entry into the index for every update that's
> being made into the table, we inevitably make a unique check against
> the older version of the newly inserted row, even when the values are
> not updated.
Robert Haas writes:
> I'm not totally sure about this but I think it's possible to do this
> without a combinatorial search. Suppose we just iterate over the list
> of
> SpecialJoinInfo structures and look for those where jointype is LEFT,
> delay_upper_joins is false, and min_righthand is a sing
On Sat, Mar 27, 2010 at 5:23 AM, Peter Eisentraut wrote:
> Per thread starting here
>
> http://archives.postgresql.org/pgsql-bugs/2010-03/msg00049.php
>
> and ending here
>
> http://archives.postgresql.org/pgsql-bugs/2010-03/msg00110.php
>
> and earlier discussions of similar nature, here is a pat
On Fri, Mar 26, 2010 at 6:10 PM, Tom Lane wrote:
>> Reading through the "optimizer functions" section of
>> src/backend/optimizer/README, it seems like the earliest point at
>> which we could do this would be just before the call to
>> make_one_rel(). I think that would eliminate some redundant
>
On Fri, 2010-03-26 at 16:16 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Sun, 2010-01-31 at 23:43 +0200, Heikki Linnakangas wrote:
> >> When replaying the deletion record, the standby could look at all the
> >> heap tuples whose index pointers are being removed, to see which one
> >> was ne
Per thread starting here
http://archives.postgresql.org/pgsql-bugs/2010-03/msg00049.php
and ending here
http://archives.postgresql.org/pgsql-bugs/2010-03/msg00110.php
and earlier discussions of similar nature, here is a patch that
separates the documentation build and installation into separate
I don't think this should involve much code change. But no-one
interested
On Sat, Mar 27, 2010 at 2:23 AM, Gokulakannan Somasundaram <
gokul...@gmail.com> wrote:
> Hi,
>Since we insert a new entry into the index for every update that's being
> made into the table, we inevitably make a uni
28 matches
Mail list logo
