On Wed, Mar 6, 2019 at 11:49 PM Justin Pryzby wrote:
>
> Hi,
>
> On Wed, Mar 06, 2019 at 04:09:46PM -0400, Kenia Vergara wrote:
> > Good afternoon.
> > I need to know the commands to display the execution time, CPU usage and
> > memory usage, but through the Postgres console.Thank you.
>
> Does th
Hi,
On Wed, Mar 06, 2019 at 04:09:46PM -0400, Kenia Vergara wrote:
> Good afternoon.
> I need to know the commands to display the execution time, CPU usage and
> memory usage, but through the Postgres console.Thank you.
Does this do what you want ? Note that the "QUERY STATISTICS" are log output
Good afternoon.
I need to know the commands to display the execution time, CPU usage and
memory usage, but through the Postgres console.Thank you.
Hello,
Thanks for the feedback so far! Continue with the previous report, we
sharing another four interesting cases that SQLFuzz discovered.
(previous discussion:
https://www.postgresql.org/message-id/flat/BN6PR07MB3409EE6CAAF8CCF43820AFB9EE670%40BN6PR07MB3409.namprd07.prod.outlook.com#acc68f0fbd8
Hi,
On 2019-03-06 19:21:33 +0100, Tobias Gierke wrote:
> On 06.03.19 18:42, Andres Freund wrote:
> >
> > It's hard to know precisely without running a profile of the
> > workload. My suspicion is that the bottleneck in this query is the use
> > of numeric, which has fairly slow operations, includ
On 06.03.19 18:42, Andres Freund wrote:
It's hard to know precisely without running a profile of the
workload. My suspicion is that the bottleneck in this query is the use
of numeric, which has fairly slow operations, including aggregation. And
they're too complicated to be inlined.
Generally t
Hi,
On 2019-03-06 18:16:08 +0100, Tobias Gierke wrote:
> I was playing around with PG11.2 (i6700k with 16GB RAM, on Ubuntu 18.04,
> compiled from sources) and LLVM, trying a CPU-bound query that in my simple
> mind should benefit from JIT'ting but (almost) doesn't.
>
> 1.) Test table with 195 col
The PostgreSQL version is 9.6.
I dont have access to the machine right now so I will check tomorrow.
Basically those values should be the same because they are updated by the
autovacuum process right ?
Any idea what else to check ? During the week last_autovacuum (in
pg_stat_all_tables) were update
Hi,
I was playing around with PG11.2 (i6700k with 16GB RAM, on Ubuntu 18.04,
compiled from sources) and LLVM, trying a CPU-bound query that in my
simple mind should benefit from JIT'ting but (almost) doesn't.
1.) Test table with 195 columns of type 'numeric':
CREATE TABLE test (data0 numeric
On Wed, Mar 06, 2019 at 06:47:21PM +0200, Mariel Cherkassky wrote:
> Those settings helped but the table still grey very much. I wrote a script
> that monitored some metadata about the table (pg_stat_all_tables,count(*)
> from orig and toasted table). I let the system monitor the table for a week
>
Hi,
I have the next relation in my db : A(id int, info bytea,date timestamp).
Every cell in the info column is very big and because of that there is a
toasted table with the data of the info column (pg_toast.pg_toast_123456).
The relation contains the login info for every user that logs into the
s
11 matches
Mail list logo
