most_common_values before the ANALYZE had 22 values. After ANALYZE it has
23 values.
After ANALYZE I get an entry for "92" with 0.0441333 frequency (the
frequency is about right).
The stats target for the "Ver" column is already at 1. I'm going to
have to bring the stats target back on everyth
On Thu, 16 Jan 2020 at 20:20, Laurenz Albe wrote:
> Well, what should the poor thing do?
> There is no index on "LucrareBugetDateId".
>
I did add an index on "LucrareBugetDateId" (before accidentally "fixing"
the problem with ANALYZE) and it didn't help.
> Rather, you have two indexes on ("Luc
Cosmin Prund writes:
> Running the same query with a different "Ver" produces a proper plan.
Oh, that *is* interesting.
After studying the code a bit more I see why this is possible when I
originally thought not. The case that you are interested in is one that
has special handling -- it's a "lo
"Finally I ran "ANALYZE" again and now the problem went away. Running the
query with Ver=92 uses the proper plan. I'm not happy with this - I know I
haven't solved the problem (I've ran ANALYZE multiple times before)."
Does 92 appear in MCVs list with that new sampling? I wonder if
default_statist
Cosmin Prund writes:
> I know it's an odd choice of plan - that's why I'm here!
Indeed. I cannot reproduce it here on 10.11:
regression=# create table bb(f1 smallint, f2 serial, primary key(f1,f2));
CREATE TABLE
regression=# explain select * from bb where f1 = 92 and f2 in (10,11);
On Thu, 2020-01-16 at 19:18 +0200, Cosmin Prund wrote:
> Indexes:
> "PK_LucrareBugetDate" PRIMARY KEY, btree ("LucrareBugetVersiuneId",
> "LucrareBugetDateId")
> "IX_LucrareBugetDate_LucrareBugetVersiuneId_LucrareBugetDateId" btree
> ("LucrareBugetVersiuneId", "LucrareBugetDateId")
> Fore
Hello Michael and hello again Tom, sorry for mailing you directly. I just
hit Reply in gmail - I expected the emails to have a reply-to=Pgsql.
Apparently they do not.
Running the same query with a different "Ver" produces a proper plan.
Here's a non-redacted example (Ver=91):
EXPLAIN (ANALYZE, BU
Michael Lewis writes:
> Does the behavior change with different values of Ver column?
By and large, indxpath.c will just add all qual clauses that match
an index to the indexscan's conditions --- there's no attempt to
decide that some of them might not be worth it on cost grounds.
So I'd be prett
Hi Tom, and thanks.
Running ANALYZE doesn't change a thing. REINDEXING doesn't change a thing.
I know it's an odd choice of plan - that's why I'm here!
I thought I'd just post what felt relevant, hoping it's not something out
of the ordinary and I'm just missing something obvious.
Here's lots of
Does the behavior change with different values of Ver column? I'd be
curious of the fraction in the MCVs frequency list in stats indicates that
rows with Ver = 92 are rare and therefore the index on only Ver column is
sufficient to find the rows quickly. What is reltuples for this table by
the way?
Cosmin Prund writes:
> explain analyze
>select R, C, V from LBD
>where Ver = 92 and Id in (10,11)
> Index Scan using "IX_LBD_Ver_Id" on "LBD" (cost=0.56..2.37 rows=1
> width=13) (actual time=0.063..857.725 rows=2 loops=1)
> Index Cond: ("Ver" = 92)
> Filter: ("Id" = ANY ('{10,11}'::i
Hello List, I'm Cosmin. This is my first post and I'll get right down to
the problem. I'm using Postgresql 10 (because that's what's installed by
default on Ubuntu 18.04):
explain analyze
select R, C, V from LBD
where Ver = 92 and Id in (10,11)
Index Scan using "IX_LBD_Ver_Id" on "LBD" (co
After migrating to a partitioned table, I noticed that a
performance-critical plpgsql function is a few times slower.
Basically, the function takes a key as an argument, and performs SELECT,
UPDATE and DELETE operations on tables partitioned by the key.
I narrowed down the problem to the following:
13 matches
Mail list logo
