Hi,
What is the compression ratio for a compressed sqlite database file?
And what is the write/read speed for compressed file comparing to a none
compressed file?
Thanks,
--Chi
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
On Friday, 20 September, 2019 10:49, Chi Ng wrote:
>What is the compression ratio for a compressed sqlite database file?
>And what is the write/read speed for compressed file comparing to a none
>compressed file?
Are you referring to:
(1) a compressed database file such as one would obtain by
The dialogue from the stackoverflow discussion shows this quite clearly.
"The code for looping over an index goes backwards only when needed. For
implementing GROUP BY itself, going backwards is never needed, so it is never
tried.
It is possible that a future SQLite version might add code to
On Thu, Sep 19, 2019 at 6:15 PM Hick Gunter wrote:
> -Ursprüngliche Nachricht-
> Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org]
> Im Auftrag von Fredrik Larsen
> Gesendet: Donnerstag, 19. September 2019 17:29
> An: SQLite mailing list
> Betreff: Re: [sqlite]
On Fri, Sep 20, 2019 at 12:33 PM Hick Gunter wrote:
> The dialogue from the stackoverflow discussion shows this quite clearly.
>
Shows what clearly Gunter? I'm not sure to follow. I've read the SO post,
and I don't get your point.
We can observe GROUP BY works ASCending only as of now. Why it
On 2019/09/20 2:49 PM, Fredrik Larsen wrote:
Hi Ryan
Nobody is proposing that QP should automagically add an index, I'm only
asking why the QP does not use already added index, that is specially added
for this specific case. I don't thinks this is a very "obscurest of
use-case" or to much to
Hi Ryan
Nobody is proposing that QP should automagically add an index, I'm only
asking why the QP does not use already added index, that is specially added
for this specific case. I don't thinks this is a very "obscurest of
use-case" or to much to ask for, in fact, this is the expected behavior
On 2019/09/20 11:12 AM, Dominique Devienne wrote:
But who says the GROUP BY must return rows in ASCending order?
A lot of us "oldies" of this ML well know the order is arbitrary and
subject to change w/o an explicit ORDER BY.
So the GROUP BY is allowed, AFAIK, to return rows in DESCending
I´m not sure why you think group_by + order_by_desc + limit N queries are
so obscure? Useful for lots of tail-statistics (number of transactions last
N hours if group_key is time-based, etc).
In my case I'm implementing a event-store using sqlite, where I need to be
able to retrieve entity data
>We can observe GROUP BY works ASCending only as of now. Why it can't work
>DESCending to avoid ordering, that's a different question.
>From https://www.sqlite.org/lang_select.html we can observe that
>GROUP BY takes an expr on the RHS, while ORDER BY takes an expr
>followed by optional COLLATE
10 matches
Mail list logo
