On Mon, Mar 29, 2010 at 3:57 PM, Robert Haas wrote:
> On Mon, Mar 29, 2010 at 3:55 PM, Tom Lane wrote:
>> Simon Riggs writes:
>>> On Mon, 2010-03-29 at 13:31 -0600, Alex Hunsaker wrote:
On Mon, Mar 29, 2010 at 12:17, Simon Riggs wrote:
> You're not addressing the original point. I have
Alex Hunsaker writes:
> It comes to mind you can probably do this with an plannerhook
> (whatever happened to those hooks to auto create/recommend indexes?)
Uh, we made some hooks to let someone build an *external* module that
would do such a thing. Whether anybody got anywhere with it I dunno.
On Mon, 2010-03-29 at 13:54 -0600, Alex Hunsaker wrote:
> whatever happened to those hooks to auto create/recommend indexes?
You haven't published them yet??
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Mon, 2010-03-29 at 15:55 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 2010-03-29 at 13:31 -0600, Alex Hunsaker wrote:
> >> On Mon, Mar 29, 2010 at 12:17, Simon Riggs wrote:
> >>> You're not addressing the original point. I have been asked how would
> >>> users know which tables hav
On Mon, Mar 29, 2010 at 3:55 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On Mon, 2010-03-29 at 13:31 -0600, Alex Hunsaker wrote:
>>> On Mon, Mar 29, 2010 at 12:17, Simon Riggs wrote:
You're not addressing the original point. I have been asked how would
users know which tables have bee
Simon Riggs writes:
> On Mon, 2010-03-29 at 13:31 -0600, Alex Hunsaker wrote:
>> On Mon, Mar 29, 2010 at 12:17, Simon Riggs wrote:
>>> You're not addressing the original point. I have been asked how would
>>> users know which tables have been removed and whether there is a way of
>>> checking tha
On Mon, Mar 29, 2010 at 13:41, Simon Riggs wrote:
>> Uhh... they wont be in the explain output... Seems simple enough.
>
> That is exactly what I replied, though nobody felt that was a great
> answer.
Maybe I missed it, but why exactly do they care? About the only
reason I can think *i* would c
On Mon, 2010-03-29 at 13:31 -0600, Alex Hunsaker wrote:
> On Mon, Mar 29, 2010 at 12:17, Simon Riggs wrote:
> > You're not addressing the original point. I have been asked how would
> > users know which tables have been removed and whether there is a way of
> > checking that.
>
> Uhh... they wont
On Mon, Mar 29, 2010 at 12:17, Simon Riggs wrote:
> You're not addressing the original point. I have been asked how would
> users know which tables have been removed and whether there is a way of
> checking that.
Uhh... they wont be in the explain output... Seems simple enough.
--
Sent via pgs
On Mon, 2010-03-29 at 11:46 -0400, Tom Lane wrote:
> Robert Haas writes:
> > OK, I'll write a patch for that; and a consensus emerges that we
> > should also have enable_joinremoval, then I will add that as well. I
> > think the only argument for NOT having enable_joinremoval is that you
> > can
On Mon, 2010-03-29 at 09:37 -0400, Robert Haas wrote:
> In many
> cases it's not horribly difficult to work around because you can do
> SELECT * FROM ... instead of your original select list, but there
> might be some cases with multiple levels of views where it isn't that
> easy. I think it woul
On Mon, 2010-03-29 at 11:27 -0400, Tom Lane wrote:
> Robert Haas writes:
> > And for the record, I believe I find it rather amusing that you're
> > asking me if I "have the faintest idea how many there would be".
>
> Actually that was directed more at Simon.
I think you should drop the personal
Tom Lane wrote:
The problem with this line of thought is that it imagines you can look
at worked-out alternative plans. You can't, because the planner doesn't
pursue rejected alternatives that far (and you'd not want to wait long
enough for it to do so...)
Not on any production system, sure
On Mon, Mar 29, 2010 at 12:17 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 29, 2010 at 12:03 PM, Greg Smith wrote:
>>> at the top of my list in this area for 9.1 is to track down the rumored
>>> patch that exports information about the rejected plans considered and get
>>> that comit
Robert Haas writes:
> On Mon, Mar 29, 2010 at 12:03 PM, Greg Smith wrote:
>> at the top of my list in this area for 9.1 is to track down the rumored
>> patch that exports information about the rejected plans considered and get
>> that comitted. That always seems what I want to look at for answer
On Mon, Mar 29, 2010 at 12:03 PM, Greg Smith wrote:
> Robert Haas wrote:
>>
>> The query planner is a great piece of code but it
>> is not so transparently simple that it doesn't need debugging or
>> instrumentation, and "why did the planner do X" has got to be one of
>> our top ten most-frequentl
Robert Haas wrote:
The query planner is a great piece of code but it
is not so transparently simple that it doesn't need debugging or
instrumentation, and "why did the planner do X" has got to be one of
our top ten most-frequently asked questions.
Debugging and instrumentation are two slightly
On Mon, Mar 29, 2010 at 11:46 AM, Tom Lane wrote:
> Robert Haas writes:
>> OK, I'll write a patch for that; and a consensus emerges that we
>> should also have enable_joinremoval, then I will add that as well. I
>> think the only argument for NOT having enable_joinremoval is that you
>> can alwa
Robert Haas writes:
> OK, I'll write a patch for that; and a consensus emerges that we
> should also have enable_joinremoval, then I will add that as well. I
> think the only argument for NOT having enable_joinremoval is that you
> can always modify the query to say SELECT * rather than some more
On Mon, Mar 29, 2010 at 11:29 AM, Robert Haas wrote:
> On Mon, Mar 29, 2010 at 11:23 AM, Jaime Casanova
> wrote:
>> On Mon, Mar 29, 2010 at 10:42 AM, Alvaro Herrera
>> wrote:
>>>
>>> It seems that what's really needed is some debug output to be able to
>>> find out what it did.
>>
>> +1, i was p
On Mon, Mar 29, 2010 at 11:27 AM, Tom Lane wrote:
> Robert Haas writes:
>> And for the record, I believe I find it rather amusing that you're
>> asking me if I "have the faintest idea how many there would be".
>
> Actually that was directed more at Simon.
>
>> I venture to say that after yourself
On Mon, Mar 29, 2010 at 11:23 AM, Jaime Casanova
wrote:
> On Mon, Mar 29, 2010 at 10:42 AM, Alvaro Herrera
> wrote:
>>
>> It seems that what's really needed is some debug output to be able to
>> find out what it did.
>
> +1, i was preparing an env for testing this but in the while i was
> thinkin
Robert Haas writes:
> And for the record, I believe I find it rather amusing that you're
> asking me if I "have the faintest idea how many there would be".
Actually that was directed more at Simon.
> I venture to say that after yourself I might be the person who knows
> this code best. I know h
On Mon, Mar 29, 2010 at 10:42 AM, Alvaro Herrera
wrote:
>
> It seems that what's really needed is some debug output to be able to
> find out what it did.
>
>
+1, i was preparing an env for testing this but in the while i was
thinking how can i know what happens... counting the tables in the
expla
On Mon, Mar 29, 2010 at 10:36 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 29, 2010 at 4:33 AM, Simon Riggs wrote:
>>> So I think we need a parameter for join removal also.
>
>> I had this in my original patch but Tom wanted it taken out.
>
> And I still don't want it. We are NOT go
Alvaro Herrera writes:
> It seems that what's really needed is some debug output to be able to
> find out what it did.
Isn't EXPLAIN good enough?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
Tom Lane escribió:
> Robert Haas writes:
> > On Mon, Mar 29, 2010 at 4:33 AM, Simon Riggs wrote:
> >> So I think we need a parameter for join removal also.
>
> > I had this in my original patch but Tom wanted it taken out.
>
> And I still don't want it. We are NOT going in the direction of add
Robert Haas writes:
> On Mon, Mar 29, 2010 at 4:33 AM, Simon Riggs wrote:
>> So I think we need a parameter for join removal also.
> I had this in my original patch but Tom wanted it taken out.
And I still don't want it. We are NOT going in the direction of adding
an enable_ knob for every sin
On Mon, Mar 29, 2010 at 4:33 AM, Simon Riggs wrote:
>
> We have planner method parameters for many important parts of the
> planner. We don't have any parameter for join removal, AFAIK.
>
> The first question I get asked is "can I see the tables it removed?".
> This has been asked of me 3 times no
We have planner method parameters for many important parts of the
planner. We don't have any parameter for join removal, AFAIK.
The first question I get asked is "can I see the tables it removed?".
This has been asked of me 3 times now this year, always first question.
Same issue applies to const
30 matches
Mail list logo
