Understood.
Thank you so much for looking into this!
Best regards,
Kristjan
On Wed, Sep 15, 2021 at 5:34 PM Tom Lane wrote:
>
> Kristjan Mustkivi writes:
> > On Wed, Sep 15, 2021 at 3:16 PM Tom Lane wrote:
> >> Note the lack of any visible cast on the varchar column, in each one of
> >> thes
Kristjan Mustkivi writes:
> On Wed, Sep 15, 2021 at 3:16 PM Tom Lane wrote:
>> Note the lack of any visible cast on the varchar column, in each one of
>> these queries, even where I tried to force one to appear. There is
>> something happening in your database that is not happening in mine.
> T
On Wed, Sep 15, 2021 at 3:16 PM Tom Lane wrote:
> Note the lack of any visible cast on the varchar column, in each one of
> these queries, even where I tried to force one to appear. There is
> something happening in your database that is not happening in mine.
>
> My mind is now running to the p
Kristjan Mustkivi writes:
> Both are of type varchar(30).
Ah, right, you showed that back at the top of the thread.
> So is this something odd: Filter: (((product_code)::text = ($1)::text)
> AND ((balance_type)::text = ($4)::text)) ?
Yes, that is very darn odd. When I try this I get:
regressi
Hello!
Both are of type varchar(30).
So is this something odd: Filter: (((product_code)::text = ($1)::text)
AND ((balance_type)::text = ($4)::text)) ?
But why does it do the type-cast if both product_code and balance_type
are of type text (although with constraint 30) and the values are also
of
Kristjan Mustkivi writes:
>>> Filter: (((product_code)::text = ($1)::text) AND
>>> ((balance_type)::text = ($4)::text))
> But the Primary Key is defined as btree (cage_code, cage_player_id,
> product_code, balance_type, version) so this should be exactly that
> (apart from the extra "version" col
On Tue, Sep 14, 2021 at 5:15 PM Tom Lane wrote:
>
> Kristjan Mustkivi writes:
> > -> Index Scan Backward using player_balance_history_idx2 on
> > mytable pbh (cost=0.70..21639.94 rows=3885 width=66) (actual
> > time=5934.153..5934.153 rows=1 loops=1)
> > Index Cond: ((
Kristjan Mustkivi writes:
> -> Index Scan Backward using player_balance_history_idx2 on
> mytable pbh (cost=0.70..21639.94 rows=3885 width=66) (actual
> time=5934.153..5934.153 rows=1 loops=1)
> Index Cond: ((cage_code = $3) AND (cage_player_id =
> $2) AND (modified_tim
I am very sorry, I indeed copy-pasted an incomplete plan. Here it is in full:
2021-09-14 06:55:33 UTC, pid=27576 db=mydb, usr=myuser, client=ip,
app=PostgreSQL JDBC Driver, line=55 LOG: duration: 5934.165 ms plan:
Query Text: SELECT * FROM myschema.mytable pbh WHERE
pbh.product_code =
On Tue, Sep 14, 2021 at 3:55 AM Kristjan Mustkivi
wrote:
> Hello Tomas,
>
> The auto explain analyze caught this:
>
> 2021-09-14 06:55:33 UTC, pid=12345 db=mydb, usr=myuser, client=ip,
> app=PostgreSQL JDBC Driver, line=55 LOG: duration: 5934.165 ms plan:
> Query Text: SELECT * FROM mysche
On Tue, 2021-09-14 at 10:55 +0300, Kristjan Mustkivi wrote:
> 2021-09-14 06:55:33 UTC, pid=12345 db=mydb, usr=myuser, client=ip,
> app=PostgreSQL JDBC Driver, line=55 LOG: duration: 5934.165 ms plan:
> Query Text: SELECT * FROM myschema.mytable pbh WHERE
> pbh.product_code = $1 AND pbh.cag
Hi Jeff,
The specialized index is present due to some other queries and the
index is used frequently (according to the statistics). I do agree
that in this particular case the index btree (cage_code,
cage_player_id, product_code, balance_type, modified_time) would solve
the problem but at the mome
Hello Tomas,
The auto explain analyze caught this:
2021-09-14 06:55:33 UTC, pid=12345 db=mydb, usr=myuser, client=ip,
app=PostgreSQL JDBC Driver, line=55 LOG: duration: 5934.165 ms plan:
Query Text: SELECT * FROM myschema.mytable pbh WHERE
pbh.product_code = $1 AND pbh.cage_player_id = $
On Mon, Sep 13, 2021 at 9:25 AM Kristjan Mustkivi
wrote:
>
> I have caught this with AUTOEXPLAIN:
>
> Index Cond: ((cage_code = $3) AND (cage_player_id = $2) AND
> (modified_time < $5))
> Filter: (((product_code)::text = ($1)::text) AND
> ((balance_type)::text = ($4)::text))
>
On Mon, Sep 13, 2021 at 9:25 AM Kristjan Mustkivi
wrote:
> SELECT
> *
> FROM
> myschema.mytable pbh
> WHERE
> pbh.product_code = $1
> AND pbh.cage_player_id = $2
> AND pbh.cage_code = $3
> AND balance_type = $4
> AND pbh.modified_time < $5
> ORDER BY
> pbh.modifie
On Mon, Sep 13, 2021 at 08:19:40AM -0600, Michael Lewis wrote:
> Autovacuum will only run for freezing, right? Insert only tables don't get
> autovacuumed/analyzed until PG13 if I remember right.
Tomas is talking about autovacuum running *analyze*, not vacuum.
It runs for analyze, except on parti
Autovacuum will only run for freezing, right? Insert only tables don't get
autovacuumed/analyzed until PG13 if I remember right.
On 9/13/21 3:24 PM, Kristjan Mustkivi wrote:
> Dear community,
>
> I have a query that most of the time gets executed in a few
> milliseconds yet occasionally takes ~20+ seconds. The difference, as
> far as I am able to tell, comes whether it uses the table Primary Key
> (fast) or an additional in
Dear community,
I have a query that most of the time gets executed in a few
milliseconds yet occasionally takes ~20+ seconds. The difference, as
far as I am able to tell, comes whether it uses the table Primary Key
(fast) or an additional index with smaller size. The table in question
is INSERT ON
19 matches
Mail list logo
