Can you explain why workaround is fast. Why one version is fast and
other slow. I'm talking about this change in where:
"and R.ID_ARHDAJ is not null"
to
"and ifnull(R.ID_ARHDAJ,0) <> 0"
For me analyze is no improvement because data is loaded from RDBMS
and would have to run always after load.
Also tested with latest version 3.30.1. For showing problem I need just
2 tables (for join).
-- cca 30.000.000 recs
CREATE TABLE ARHDAJ(
ID_ARHDAJ integer primary key autoincrement,
ID_ARHPLA integer,
R integer,
O decimal(8,4),
Z decimal(12,2),
VEZA varchar(8) collate systemnocase);
On Friday, 6 December, 2019 08:17, radovan5 wrote:
>ANALYZE dosn't help because data is loaded from RDBMS
>for processing every time.
From this I take is that you are loading the data from somewhere else and then
running this one query and you do not want to run ANALYZE. If that is the case
Hello, Radovan,
Regarding: "ANALYZE doesn't help because data is loaded from RDBMS
for processing every time."
You can avoid the workaround, have "almost instant" analyze, and insure
against some types of inefficient queries in future by:
1. Running analyze on a representative working
s).
--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a
lot about anticipated traffic volume.
>-Original Message-
>From: sqlite-users On
>Behalf Of radovan5
>Sent: Friday, 6 December, 2019 08:16
>To: sqlite-users@mailinglists.sqlite.org
>Subje
Sent: Friday, December 6, 2019 10:16 AM
To: sqlite-users@mailinglists.sqlite.org
Subject: Re: [sqlite] Changes in version 3.28.0 makes sql run slower
Can you explain why workaround is fast. Why one version is fast and
other slow. I'm talking about this change in where:
"and R.ID_ARHDAJ
ANALYZE dosn't help because data is loaded from RDBMS
for processing every time.
Why this change give different times (nobody is interested):
"and R.ID_ARHDAJ is not null"
to
"and ifnull(R.ID_ARHDAJ,0) <> 0"
Regards Radovan
On 06.12.2019 15:52, Simon Slavin wrote:
On 6 Dec 2019, at
Can you explain why workaround is fast. Why one version is fast and
other slow. I'm talking about this change in where:
"and R.ID_ARHDAJ is not null"
to
"and ifnull(R.ID_ARHDAJ,0) <> 0"
For me analyze is no improvement because data is loaded from RDBMS
and would have to run always after load.
On 6 Dec 2019, at 10:05am, radovan5 wrote:
> Just in my case analyze is quite slow also. So in the end I get same time. It
> is faster to use just workaround in sql.
The results of ANALYZE are stored in the database. So although the total time
is about the same when you do run it, once you
On Fri, Dec 6, 2019 at 2:21 PM Richard Hipp wrote:
> On 12/6/19, Keith Medcalf wrote:
> >
> > Perhaps the optimizer could make a "left join" that is not actually an
> outer
> > join into a "cross join" and preserve the nesting order ... ?
>
> It could do that, but that would kind of defeat the
On 12/6/19, Keith Medcalf wrote:
>
> Perhaps the optimizer could make a "left join" that is not actually an outer
> join into a "cross join" and preserve the nesting order ... ?
>
It could do that, but that would kind of defeat the whole purpose of
the optimization, which was to free up the
Well I have to write sql like that because I must have one table in
from. Some component I have
depend on this. This has worked fast before but I have workaround so is
not a problem.
Regards Radovan
On 06.12.2019 11:35, Keith Medcalf wrote:
The join that you are using is not an outer join
The join that you are using is not an outer join because you have constrained
R.ID_ARHDAJ (which cannot be null in the table) to not be null, and the only
way it can be null is if the left join is a "miss", meaning that it is really
an inner join, not an outer join). The optimizer spots this
On 06.12.2019 10:33, Shawn Wagner wrote:
> Does running an ANALYZE have any impact?
>
On Fri, Dec 6, 2019 at 11:06 AM radovan5 wrote:
> Yes it has and I get correct plan. Did not use analyze before or pragma
> optimize
> but I see I would have to. Thank you for reminding me to this. Just in my
Yes it has and I get correct plan. Did not use analyze before or pragma
optimize
but I see I would have to. Thank you for reminding me to this. Just in
my case
analyze is quite slow also. So in the end I get same time. It is faster
to use just
workaround in sql.
Regards Radovan
On 06.12.2019
Does running an ANALYZE have any impact?
On Fri, Dec 6, 2019 at 12:47 AM radovan5 wrote:
> Also tested with latest version 3.30.1. For showing problem I need just
> 2 tables (for join).
>
> -- cca 30.000.000 recs
> CREATE TABLE ARHDAJ(
>ID_ARHDAJ integer primary key autoincrement,
>
Also tested with latest version 3.30.1. For showing problem I need just
2 tables (for join).
-- cca 30.000.000 recs
CREATE TABLE ARHDAJ(
ID_ARHDAJ integer primary key autoincrement,
ID_ARHPLA integer,
R integer,
O decimal(8,4),
Z decimal(12,2),
VEZA varchar(8) collate systemnocase);
17 matches
Mail list logo
