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 unique
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
On Fri, 2010-03-26 at 16:16 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
On Fri, Mar 26, 2010 at 6:10 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sat, Mar 27, 2010 at 5:23 AM, Peter Eisentraut pete...@gmx.net 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
Robert Haas robertmh...@gmail.com 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
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. Of
On Sat, Mar 27, 2010 at 10:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Sat, Mar 27, 2010 at 10:10 AM, Simon Riggs si...@2ndquadrant.com 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,
On Fri, Mar 26, 2010 at 10:19 PM, Joseph Adams
joeyadams3.14...@gmail.com 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
On Sat, 2010-03-27 at 19:15 +, Greg Stark wrote:
On Sat, Mar 27, 2010 at 10:10 AM, Simon Riggs si...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com writes:
On Sat, Mar 27, 2010 at 10:50 AM, Tom Lane t...@sss.pgh.pa.us 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
On Sat, Mar 27, 2010 at 4:11 PM, Tom Lane t...@sss.pgh.pa.us 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
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'.
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
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.
Hi,
The function outDatum doesn't take care of varlena structures which are
stored externally. Is it the intention??
Thanks,
Gokul.
On Sat, Mar 27, 2010 at 7:36 PM, Simon Riggs si...@2ndquadrant.com 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
Gokulakannan Somasundaram gokul...@gmail.com 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
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),
On Sat, Mar 27, 2010 at 10:08 PM, Jaime Casanova
jcasa...@systemguards.com.ec 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
On Sat, Mar 27, 2010 at 10:08 PM, Jaime Casanova
jcasa...@systemguards.com.ec 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
Robert Haas robertmh...@gmail.com writes:
On Sat, Mar 27, 2010 at 4:11 PM, Tom Lane t...@sss.pgh.pa.us 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.
Robert Haas robertmh...@gmail.com writes:
On Sat, Mar 27, 2010 at 10:08 PM, Jaime Casanova
jcasa...@systemguards.com.ec 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
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.
On Sun, Mar 28, 2010 at 12:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Jaime Casanova jcasa...@systemguards.com.ec 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
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 any
28 matches
Mail list logo
