Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

Mark Dilger writes: >> The swtich in src/backend/parser/analyze.c circa line 2819 should >> probably have an explicit case for RTE_RESULT rather than just a >> comment and allowing the default to log "unrecognized RTE type", >> since it's not really unrecognized, just unexpected. But I'm not >>

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

David Rowley wrote: > hmm. You both know the table of that name exists only as part of a > regression test, right? It'll just exist for a handful of > milliseconds during make check. Er, I wasn't aware of that, as I didn't read the patch. Then I think my comment should be discarded as being

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

On Mon, 28 Jan 2019 at 22:31, Laurenz Albe wrote: > > Stefan Keller wrote: > > Pls. try to give DUAL a better name, since it's IMHO neither > > self-explaining nor correct. > > I agree with the sentiment. > On the other hand, people who migrate from Oracle might be happy if > there is a DUAL

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

Stefan Keller wrote: > Pls. try to give DUAL a better name, since it's IMHO neither > self-explaining nor correct. I agree with the sentiment. On the other hand, people who migrate from Oracle might be happy if there is a DUAL table that allows them to migrate some of their statements unmodified.

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

Dear all, I'm following this list since years - especially PostGIS related - and you and PG are just awesome! Pls. let me chime in as a university teacher, therefore used to explain every year the same things :-). My 2 cents here are: Pls. try to give DUAL a better name, since it's IMHO neither

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

> On Jan 27, 2019, at 12:04 PM, Mark Dilger wrote: > > > >> On Jan 25, 2019, at 5:09 PM, Tom Lane wrote: >> >> David Rowley writes: >>> As far as I can see the patch is ready to go, but I'll defer to Mark, >>> who's also listed on the reviewer list for this patch. >> >> Mark, are you

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

> On Jan 25, 2019, at 5:09 PM, Tom Lane wrote: > > David Rowley writes: >> As far as I can see the patch is ready to go, but I'll defer to Mark, >> who's also listed on the reviewer list for this patch. > > Mark, are you planning to do further review on this patch? > I'd like to move it

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

> On Jan 25, 2019, at 5:09 PM, Tom Lane wrote: > > David Rowley writes: >> As far as I can see the patch is ready to go, but I'll defer to Mark, >> who's also listed on the reviewer list for this patch. > > Mark, are you planning to do further review on this patch? > I'd like to move it

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

David Rowley writes: > As far as I can see the patch is ready to go, but I'll defer to Mark, > who's also listed on the reviewer list for this patch. Mark, are you planning to do further review on this patch? I'd like to move it along, since (IMO anyway) we need it in before progress can be made

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

On Tue, 15 Jan 2019 at 13:17, Tom Lane wrote: > > David Rowley writes: > > I also did a quick benchmark of v6 and found the slowdown to be > > smaller after the change made in build_simple_rel() > > Thanks for confirming. I was not very sure that was worth the extra > few bytes of code space,

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

On Tue, 15 Jan 2019 at 13:17, Tom Lane wrote: > > David Rowley writes: > > 1. I don't think having a table named "dual" makes a whole lot of > > sense for a table with a single row. > > Well, I borrowed Oracle terminology there ;-) yep, but ... go on... break the mould :) -- David Rowley

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

David Rowley writes: > 1. I don't think having a table named "dual" makes a whole lot of > sense for a table with a single row. Well, I borrowed Oracle terminology there ;-) > (Uppercasing these additions would also make them look less of an > afterthought.) Don't really care, can do. > I

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

On Tue, 15 Jan 2019 at 09:48, Tom Lane wrote: > > David Rowley writes: > > SELECT 1; I believe is a common query for some connection poolers as a > > sort of ping to the database. In light of that, the performance drop > > of 2 microseconds per query is not going to amount to very much in > >

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

David Rowley writes: > I ran a few benchmarks on an AWS m5d.large instance based on top of > c5c7fa261f5. The biggest regression I see is from a simple SELECT 1 at > around 5-6%. A repeat of your test of SELECT 2+2 showed about half > that regression so the simple addition function call is

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

On Sat, 5 Jan 2019 at 08:48, Tom Lane wrote: > v5 attached; this responds to your comments plus Alexander's earlier > gripe about not getting a clean build with --disable-cassert. > No really substantive changes though. I ran a few benchmarks on an AWS m5d.large instance based on top of

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

I wrote: > If you reverse out just that change you'll see why I added it: without it, > the plan for the earlier "test a corner case in which we shouldn't apply > the star-schema optimization" isn't optimized as much as I thought it > should be. Hmm ... looking at this closer, it seems like this

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

David Rowley writes: > I've just looked over the v4 patch. I agree that having an RTE for a > from-less SELECT seems like a good idea. Thanks for looking! > While reading the patch, I noted the following: > 1. It's more efficient to use bms_next_member as it does not need to > re-skip 0 words

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

I've just looked over the v4 patch. I agree that having an RTE for a from-less SELECT seems like a good idea. While reading the patch, I noted the following: 1. It's more efficient to use bms_next_member as it does not need to re-skip 0 words on each iteration. (Likely bms_first_member() is not

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

On 11/29/18 22:13, Tom Lane wrote: Ooops, I had not seen this before sending v4 patch. Doesn't seem worth posting a v5 for, but I'll be sure to fix it. Thanks for updating, v4 looks good to me. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

Alexander Kuzmenkov writes: > Oh, one more thing: I see a warning without --enable-cassert in > create_resultscan_plan, because rte is only used in an Assert. > src/backend/optimizer/plan/createplan.c:3457:17: warning: variable ‘rte’ > set but not used [-Wunused-but-set-variable] >  

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

Alexander Kuzmenkov writes: > I was also looking at this patch, here are some things I noticed: Thanks for reviewing! I incorporated your suggestions in the v4 patch I just sent. regards, tom lane

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

Mark Dilger writes: > Patch applies cleanly on master (b238527664ec6f6c9d00dba4cc2f3dab1c8b8b04), > compiles, and passes both 'make check-world' and 'make installcheck-world'. Thanks for reviewing! > The patch includes changes to the expected output of a few tests, and adds > new code

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

Oh, one more thing: I see a warning without --enable-cassert in create_resultscan_plan, because rte is only used in an Assert. src/backend/optimizer/plan/createplan.c:3457:17: warning: variable ‘rte’ set but not used [-Wunused-but-set-variable]   RangeTblEntry *rte; -- Alexander Kuzmenkov

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

I was also looking at this patch, here are some things I noticed: In remove_useless_results_recurse where it processes JOIN_SEMI there is this comment:             * However, we can't simplify if there are PHVs to evaluate at                  * the RTE_RESULT ... but that's impossible

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: not tested Spec compliant: not tested Documentation:not tested Sorry about the prior review; I neglected to select all the appropriate

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: not tested Spec compliant: not tested Documentation:not tested Patch applies cleanly on master

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

I wrote: > * There's a hack in nodeResult.c to prevent the executor from crashing > on a whole-row Var for an RTE_RESULT RTE, which is something that the > planner will create in SELECT FOR UPDATE cases, because it thinks it > needs to provide a ROW_MARK_COPY image of the RTE's output. We might >

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

On Fri, Mar 16, 2018 at 4:27 AM Tom Lane wrote: > We've long made fun of Oracle(TM) for the fact that if you just want > to evaluate some expressions, you have to write "select ... from dual" > rather than just "select ...". But I've realized recently that there's > a bit of method in that

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

Robert Haas writes: > On Thu, Mar 15, 2018 at 11:27 AM, Tom Lane wrote: >> We've long made fun of Oracle(TM) for the fact that if you just want >> to evaluate some expressions, you have to write "select ... from dual" >> rather than just "select ...". But I've realized recently that there's >>

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

Ashutosh Bapat writes: > On Thu, Mar 15, 2018 at 8:57 PM, Tom Lane wrote: >> Suppose that, either in the rewriter or early in the planner, we were >> to replace such cases with nonempty FromExprs, by adding a dummy RTE >> representing a table

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

On Thu, Mar 15, 2018 at 8:57 PM, Tom Lane wrote: > We've long made fun of Oracle(TM) for the fact that if you just want > to evaluate some expressions, you have to write "select ... from dual" > rather than just "select ...". But I've realized recently that there's > a bit of

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

On Thu, Mar 15, 2018 at 11:27 AM, Tom Lane wrote: > We've long made fun of Oracle(TM) for the fact that if you just want > to evaluate some expressions, you have to write "select ... from dual" > rather than just "select ...". But I've realized recently that there's > a bit