Are you sure you're using the same data det ?
Unless I'm overlooking something obvious one result has 500 000 rows the
other 7 000.
>
On Fri, May 7, 2021 at 2:28 PM Peter Geoghegan wrote:
> That's a very reasonable interpretation, since the bitmap index scans
> themselves just aren't doing that much I/O -- we see that there is
> much more I/O for the heap scan, which is likely to be what the
> general picture looks like no matte
On Fri, May 7, 2021 at 9:16 AM Justin Pryzby wrote:
> In pg13, indexes are de-duplicated by default.
>
> But I suspect the performance is better because data was reload, and the
> smaller indexes are a small, additional benefit.
That's a very reasonable interpretation, since the bitmap index scan
Justin Pryzby writes:
> On Fri, May 07, 2021 at 05:57:19PM +0200, Semen Yefimenko wrote:
>> For testing purposes I set up a separate postgres 13.2 instance on windows.
>> To my surprise, it works perfectly fine. Also indexes, have about 1/4 of
>> the size they had on 12.6.
> In pg13, indexes are
On Fri, May 07, 2021 at 05:57:19PM +0200, Semen Yefimenko wrote:
> For testing purposes I set up a separate postgres 13.2 instance on windows.
> To my surprise, it works perfectly fine. Also indexes, have about 1/4 of
> the size they had on 12.6.
In pg13, indexes are de-duplicated by default.
But
For testing purposes I set up a separate postgres 13.2 instance on windows.
To my surprise, it works perfectly fine. Also indexes, have about 1/4 of
the size they had on 12.6.
I'll try setting up a new 12.6 instance and see if I can reproduce
anything.
This explain plan is on a SSD local postgres
On Thu, May 6, 2021 at 10:38 AM Semen Yefimenko
wrote:
> Hi there,
>
> I've recently been involved in migrating our old system to SQL Server and
> then PostgreSQL. Everything has been working fine so far but now after
> executing our tests on Postgres, we saw a very slow running query on a
> larg
Is this on windows ?
I see a thread that mentions of performance penalty due to parallel worker
There is a mailing thread with subject line -
Huge performance penalty with parallel queries in Windows x64 v. Linux x64
On Fri, 7 May 2021 at 2:33 PM Semen Yefimenko
wrote:
> As mentionend in th
As mentionend in the slack comments :
SELECT pg_size_pretty(pg_relation_size('logtable')) as table_size,
pg_size_pretty(pg_relation_size('idx_entrytype')) as index_size,
(pgstattuple('logtable')).dead_tuple_percent;
table_size | index_size | dead_tuple_percent
++--
ok one last thing, not to be a PITA, but just in case if this helps.
postgres=# SELECT * FROM pg_stat_user_indexes where relname = 'logtable';
postgres=# SELECT * FROM pg_stat_user_tables where relname = 'logtable';
basically, i just to verify if the table is not bloated.
looking at *n_live_tup* v
Sorry if I'm cumulatively answering everyone in one E-Mail, I'm not sure
how I'm supposed to do it. (single E-Mails vs many)
> Can you try tuning by increasing the shared_buffers slowly in steps of
> 500MB, and running explain analyze against the query.
-- 2500 MB shared buffers - random_page_c
11 matches
Mail list logo
