Re: [HACKERS] Optimizer questions

I wrote: > As far as that goes, it seems to me after thinking about it that > non-sort-column tlist items containing SRFs should always be postponed, > too. Performing a SRF before sorting bloats the sort data vertically, > rather than horizontally, but it's still bloat. (Although as against >

Re: [HACKERS] Optimizer questions

konstantin knizhnik writes: > But right now the rule for cost estimation makes it not possible to apply > this optimization for simple expressions like this: ... > I wonder is there any advantages of earlier evaluation of such simple > expressions if them are not

Re: [HACKERS] Optimizer questions

On Mar 10, 2016, at 1:56 AM, Tom Lane wrote: > Konstantin Knizhnik writes: >> I think that the best approach is to generate two different paths: >> original one, when projection is always done before sort and another one >> with postponed projection of non-trivial

Re: [HACKERS] Optimizer questions

Konstantin Knizhnik writes: > I think that the best approach is to generate two different paths: > original one, when projection is always done before sort and another one > with postponed projection of non-trivial columns. Then we compare costs > of two paths and

Re: [HACKERS] Optimizer questions

On 09.03.2016 09:15, Tom Lane wrote: I wrote: BTW, there's some additional refactoring I had had in mind to do in grouping_planner to make its handling of the targetlist a bit more organized; in particular, I'd like to see it using PathTarget representation more consistently throughout the

Re: [HACKERS] Optimizer questions

I wrote: > BTW, there's some additional refactoring I had had in mind to do in > grouping_planner to make its handling of the targetlist a bit more > organized; in particular, I'd like to see it using PathTarget > representation more consistently throughout the post-scan-join steps. See

Re: [HACKERS] Optimizer questions

Konstantin Knizhnik writes: > On 03/08/2016 07:01 AM, Tom Lane wrote: >> I've not spent a lot of time on this, but I think maybe what would make >> sense is to consider both the case where function calculations are >> postponed to after ORDER BY and the case where they

Re: [HACKERS] Optimizer questions

On 03/08/2016 07:01 AM, Tom Lane wrote: Konstantin Knizhnik writes: Attached please find improved version of the optimizer patch for LIMIT clause. This patch isn't anywhere close to working after 3fc6e2d7f5b652b4. (TBH, the reason I was negative about this upthread

Re: [HACKERS] Optimizer questions

Tom Lane wrote: > Konstantin Knizhnik writes: > > Attached please find improved version of the optimizer patch for LIMIT > > clause. > For now, I've set this commitfest entry to Waiting on Author. There's > still time to consider a rewrite in this 'fest, if you can

Re: [HACKERS] Optimizer questions

Konstantin Knizhnik writes: > Attached please find improved version of the optimizer patch for LIMIT clause. This patch isn't anywhere close to working after 3fc6e2d7f5b652b4. (TBH, the reason I was negative about this upthread is that I had that one in the oven and

Re: [HACKERS] Optimizer questions

Unfortunately this two statements are not equivalent: second one can (in theory, but not for this particular data set) return more than 10 result records. Such optimization will be correct if t2.i is declared as unique. But the most efficient plan for this query will be generated if there is

Re: [HACKERS] Optimizer questions

On Fri, Jan 8, 2016 at 11:58 AM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > Attached please find improved version of the optimizer patch for LIMIT > clause. > Now I try to apply this optimization only for non-trivial columns > requiring evaluation. > May be it will be better to

Re: [HACKERS] Optimizer questions

Le 18/01/2016 03:47, Bruce Momjian a écrit : > On Tue, Jan 5, 2016 at 05:55:28PM +0300, konstantin knizhnik wrote: >> Hi hackers, >> >> I want to ask two questions about PostgreSQL optimizer. >> I have the following query: >> >> SELECT o.id as id,s.id as sid,o.owner,o.creator,o.parent_id >> as

Re: [HACKERS] Optimizer questions

I am sorry for badly formatted query - I just cut it from C++ client program. I have one more question to community regarding this patch. Proposed patch fix the problem particularly for SORT+LIMIT clauses. In this case evaluation of expressions which are not used in sort is alway waste of

Re: [HACKERS] Optimizer questions

On Tue, Jan 5, 2016 at 05:55:28PM +0300, konstantin knizhnik wrote: > Hi hackers, > > I want to ask two questions about PostgreSQL optimizer. > I have the following query: > > SELECT o.id as id,s.id as sid,o.owner,o.creator,o.parent_id > as

Re: [HACKERS] Optimizer questions

Attached please find improved version of the optimizer patch for LIMIT clause. Now I try to apply this optimization only for non-trivial columns requiring evaluation. May be it will be better to take in account cost of this columns evaluation but right now I just detect non-variable columns.

Re: [HACKERS] Optimizer questions

On 01/06/2016 12:03 PM, David Rowley wrote: Konstantin, are you thinking of looking into this more, with plans to implement code to improve this? I am not familiar with PostgreSQL optimizer, but I now looking inside its code and trying to find a way to fix this problem. But if there is

Re: [HACKERS] Optimizer questions

On 6 January 2016 at 13:13, Alexander Korotkov wrote: > On Wed, Jan 6, 2016 at 12:08 AM, Tom Lane wrote: > >> konstantin knizhnik writes: >> > 1. The cost compared in grouping_planner doesn't take in account price >> of

Re: [HACKERS] Optimizer questions

On 6 January 2016 at 09:03, David Rowley wrote: > It seems worthwhile to investigate how we might go about improving this so > that the evaluation of the target list happens after LIMIT, at least for > the columns which are not required before LIMIT. > Currently,

[HACKERS] Optimizer questions

Hi hackers, I want to ask two questions about PostgreSQL optimizer. I have the following query: SELECT o.id as id,s.id as sid,o.owner,o.creator,o.parent_id as dir_id,s.mime_id,m.c_type,s.p_file,s.mtime,o.ctime,o.name,o.title,o.size,o.deleted,la.otime,la.etime,uo.login as owner_login,uc.login

Re: [HACKERS] Optimizer questions

konstantin knizhnik writes: > 1. The cost compared in grouping_planner doesn't take in account price of > get_authorized_users - it is not changed when I am altering function cost. Is > it correct behavior? The general problem of accounting for tlist eval cost is not

Re: [HACKERS] Optimizer questions

On Wed, Jan 6, 2016 at 12:08 AM, Tom Lane wrote: > konstantin knizhnik writes: > > 1. The cost compared in grouping_planner doesn't take in account price > of get_authorized_users - it is not changed when I am altering function > cost. Is it

Re: [HACKERS] optimizer questions

--On Dienstag, Februar 14, 2006 10:35:12 -0600 hector Corrada Bravo [EMAIL PROTECTED] wrote: Before I start trying this (creating aggregate paths seems the reasonable thing to do) I would like your counsel. 1) Regardless of the optimization problem, is the executor able to execute aggregate

[HACKERS] optimizer questions

Hello everyone, I am working with the Postgres optimizer for the first time, so bear with me... I want to extend the optimizer to deal with aggregate queries a bit better. The idea is from an old paper by Chaudhuri and Shim in VLDB 94. The gist of it is that when computing aggregates over the

Re: [HACKERS] optimizer questions

On Tue, Feb 14, 2006 at 10:35:12AM -0600, hector Corrada Bravo wrote: Hello everyone, I am working with the Postgres optimizer for the first time, so bear with me... I want to extend the optimizer to deal with aggregate queries a bit better. The idea is from an old paper by Chaudhuri and

Re: [HACKERS] optimizer questions

hector Corrada Bravo [EMAIL PROTECTED] writes: 1) Regardless of the optimization problem, is the executor able to execute aggregate nodes within join trees (that is, not as the result of subqueries)? Sure. 3) For debugging purposes: Has anyone figured out a way to feed hand-crafted plans to