Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement subqueries #52

Closed
jvshahid opened this issue Nov 13, 2013 · 20 comments
Closed

Implement subqueries #52

jvshahid opened this issue Nov 13, 2013 · 20 comments

Comments

@jvshahid
Copy link
Contributor

No description provided.

@ghost ghost assigned jvshahid Dec 5, 2013
@jvshahid jvshahid modified the milestones: 0.8.0, 0.7.0 May 2, 2014
jvshahid pushed a commit that referenced this issue Aug 12, 2014
jvshahid pushed a commit that referenced this issue Aug 12, 2014
@jvshahid
Copy link
Contributor Author

This was closed by accident because we just merged in the upstream raft history. Reopening

@jvshahid jvshahid reopened this Aug 12, 2014
@jvshahid jvshahid modified the milestones: 0.8.0, Next release Aug 25, 2014
@jvshahid jvshahid modified the milestone: Next release Oct 9, 2014
@toddboom toddboom added the idea label Oct 23, 2014
@jmorales4
Copy link

+1 for this feature

@ross-nordstrom
Copy link

+1

@Dragomir-Ivanov
Copy link

+1

1 similar comment
@pasancario
Copy link

+1

@multilinear
Copy link

When you do this, please make it arbitrarilly recursive, rather than just adding one-level. In other words, subqueries should be allowed to have subqueries :). Limiting it to 2 levels is as silly as limiting it to 1.

@gillesdemey
Copy link

+1, here's a sentence that explains my use-case:

I want to retrieve all data points from my latency measurement that are within the 90th percentile.

SELECT ms FROM latency WHERE time > now() - 2h AND ms < (SELECT percentile(ms, 90) FROM latency)

@paul91
Copy link

paul91 commented Mar 31, 2015

+1

@salanki
Copy link

salanki commented May 19, 2015

+1

@Melevir
Copy link

Melevir commented Jun 26, 2015

Does "revisit in the future" means it won't be implemented in 0.9.x?

@beckettsean
Copy link
Contributor

@Melevir that is correct. The "revisit in the future" label is for features beyond the 0.9 line.

@hotsnow77
Copy link

+1
I my case I'd like to do a first aggregation with a small group time and over that another aggregation with a bigger group time

@morganda
Copy link

+1

3 similar comments
@timgriffiths
Copy link

+1

@13h3r
Copy link

13h3r commented May 11, 2016

+1

@siddarth7
Copy link

+1

@coding-jj
Copy link

+1

2 similar comments
@bedrin
Copy link

bedrin commented Aug 3, 2016

+1

@asimell
Copy link

asimell commented Aug 16, 2016

+1

@lexmag
Copy link

lexmag commented Aug 16, 2016

Rather than +1 in comments it's way better to react 👍 under initial comment.
There are many people who have subscribed to this issue to get a notification when it will be closed (hopefully implemented), and those +1 only create unnecessary noise for everyone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests