WaitForMultipleObjects in C Extension

Hi guys I need your experiences. I made an Extension in C. When I stop the query on PostgreSQL,I want to control my extension's result with use cases in C.So I think , I should use WaitForMultipleObjects. Is there a like a SignalObjectHandle() ? By the way I'm using Windows. Thanks...

Re: pg_stat_statements extension

On Mon, Jan 13, 2020 at 11:41:36AM -0800, Adrian Klaver wrote: > How did the above get installed, from source, RPM. other? Rushikesh, depending on your environment, the way to install pg_stat_statements' libraries may change. On most Linux distributions, any extension modules are shipped with a p

Re: Worse performance with higher work_mem?

On Tue, Jan 14, 2020 at 5:29 AM Israel Brewster wrote: > > I was working on diagnosing a “slow” (about 6 second run time) query: > > SELECT > to_char(bucket,'-MM-DD"T"HH24:MI:SS') as dates, > x_tilt, > y_tilt, > rot_x, > rot_y, >

Re: Worse performance with higher work_mem?

> On Jan 13, 2020, at 5:41 PM, Israel Brewster wrote: > >> On Jan 13, 2020, at 3:19 PM, Tom Lane > > wrote: >> >> Israel Brewster mailto:ijbrews...@alaska.edu>> >> writes: >>> In looking at the explain analyze output, I noticed that it had an >>> “external merge Di

Re: Worse performance with higher work_mem?

> On Jan 13, 2020, at 3:19 PM, Tom Lane wrote: > > Israel Brewster writes: >> In looking at the explain analyze output, I noticed that it had an “external >> merge Disk” sort going on, accounting for about 1 second of the runtime >> (explain analyze output here: https://explain.depesz.com/s/jx

Re: Worse performance with higher work_mem?

Israel Brewster writes: > In looking at the explain analyze output, I noticed that it had an “external > merge Disk” sort going on, accounting for about 1 second of the runtime > (explain analyze output here: https://explain.depesz.com/s/jx0q > ). Since the ma

Worse performance with higher work_mem?

I was working on diagnosing a “slow” (about 6 second run time) query: SELECT to_char(bucket,'-MM-DD"T"HH24:MI:SS') as dates, x_tilt, y_tilt, rot_x, rot_y, date_part('epoch', bucket) as timestamps, temp

Re: pg_stat_statements extension

On 1/13/20 11:29 AM, Rushikesh socha wrote: HI its 11.5                                                  version -  PostgreSQL 11.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 201506

Re: pg_stat_statements extension

HI its 11.5 version - PostgreSQL 11.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit Thanks. Rushikesh

Re: pg_stat_statements extension

On 1/13/20 11:15 AM, Rushikesh socha wrote: HI, Is there any good link that shows how to install pg_stat_statements extension Postgres version? How did you install Postgres? I am getting below error postgres=# CREATE EXTENSION pg_stat_statements; ERROR:  could not open extension control fil

pg_stat_statements extension

HI, Is there any good link that shows how to install pg_stat_statements extension I am getting below error postgres=# CREATE EXTENSION pg_stat_statements; ERROR: could not open extension control file "/usr/pgsql-11/share/extension/pg_stat_statements.control": No such file or directory Thanks.

Re: pg_repack in cluster

On 1/13/20 7:41 AM, dagamier wrote: Can't afford the downtime of a "vaccuum full" and the autovacuum process is not cleaning up all the dead space tied up by the database. pg_repack works great on my test database in reclaiming disk space (in my tests I got back 46% of my disk space back) due to

Re: pg_repack in cluster

Can't afford the downtime of a "vaccuum full" and the autovacuum process is not cleaning up all the dead space tied up by the database. pg_repack works great on my test database in reclaiming disk space (in my tests I got back 46% of my disk space back) due to all the deletions that happen in our t

No partition pruning when initializing query plan with LATERAL JOIN and aggregates

I wonder why partition pruning doesn't work with LATERAL JOIN and aggregates. Below is my example tested on PostgreSQL 12.1 (Ubuntu 12.1-1.pgdg18.04+1): CREATE TABLE demo(key BIGINT) PARTITION BY LIST (key); CREATE TABLE demo_key_1 PARTITION OF demo FOR VALUES IN (1); CREATE TABLE demo_key_2 PARTI