Re: [GENERAL] How the Planner in PGStrom differs from PostgreSQL?

"fraction of the cost of executing the same portion of the plan using the traditional CPU processing" Can u explain about this fraction in detail? I need the clarifications for query plan tree also. Executing a query in CPU is different from executing the same in GPU. So the plan also differs.

Re: [GENERAL] pgbench and scaling

I forgot to mention that the db is replicated synchronously. I think that is the culprit. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] pgbench and scaling

PG 9.5.3 RHEL Linux To cut the story short and giving as much details as I can remember: I created 40 database db1 .. db40 in a cluster. On each database I initialized pgbench tables with a scale of 15. Then I concurrently ran 5 pgbenches for 15 min. Each pgbench connected to one db. In other

Re: [GENERAL] pg_class (system) table increasing size.

On Thu, Nov 17, 2016 at 3:16 PM, Alvaro Herrera wrote: > Looks like you lost the stat data awhile ago (probably due to a server > crash, or pg_stats_reset()) and it never got updated. I suggest doing > "ANALZYE pg_class" to create initial stats; that might prompt

Re: [GENERAL] pg_class (system) table increasing size.

dhaval jaiswal wrote: > select * from pg_stat_sys_tables where relname = 'pg_class'; > > -[ RECORD 1 ]---+--- > relid | 1259 > schemaname | pg_catalog > relname | pg_class > seq_scan| 1838 > seq_tup_read| 3177416 > idx_scan

Re: [GENERAL] pg_class (system) table increasing size.

On Thu, Nov 17, 2016 at 1:33 PM, dhaval jaiswal wrote: > select * from pg_stat_sys_tables where relname = 'pg_class'; > > -[ RECORD 1 ]---+--- > relid | 1259 > schemaname | pg_catalog > relname | pg_class > seq_scan

Re: [GENERAL] help with moving tablespace

> Bonus question: I found an ER diagram of some of the pg_* tables at h > ttp://www.slideshare.net/oddbjorn/Get-to-know-PostgreSQL. Is there an > ERD of all of them so a person can better understand how to use them > when one must? I suppose the same question applies to > information_schema since

Re: [GENERAL] pg_class (system) table increasing size.

select * from pg_stat_sys_tables where relname = 'pg_class'; -[ RECORD 1 ]---+--- relid | 1259 schemaname | pg_catalog relname | pg_class seq_scan| 1838 seq_tup_read| 3177416 idx_scan| 1027456557 idx_tup_fetch |

Re: [GENERAL] help with moving tablespace

> On Thu, Nov 17, 2016 wrote: > > On Thu, Nov 17, 2016 at 9:16 AM, wrote: > > First, the above works only *most* of the time in our testing on multiple > > servers. When it fails, it's because not everything was moved out of the > > old

Re: [GENERAL] Streaming replication failover/failback

On Nov 16, 2016, at 11:39 PM, Jehan-Guillaume de Rorthais wrote: > > On Wed, 16 Nov 2016 15:51:26 -0900 > Israel Brewster > wrote: > >> I've been playing around with streaming replication, and discovered that the >> following

Re: [GENERAL] Streaming replication failover/failback

> On Nov 16, 2016, at 4:24 PM, Adrian Klaver wrote: > > On 11/16/2016 04:51 PM, Israel Brewster wrote: >> I've been playing around with streaming replication, and discovered that >> the following series of steps *appears* to work without complaint: >> >> - Start

Re: [GENERAL] help with moving tablespace

On Thu, Nov 17, 2016 at 9:16 AM, wrote: > First, the above works only *most* of the time in our testing on multiple > servers. When it fails, it's because not everything was moved out of the > old tablespace and I don't understand why. An "ls $PGDATA/ourdb/PG*/" shows >

[GENERAL] help with moving tablespace

Back in the early dawn of time (before I came here :) the tablespace for our DB was put under the data dir, which gives us the warning "tablespace location should not be inside the data directory", which I'm trying to fix -- and I'm also trying to fix ownerships so everything isn't owned by

Re: [GENERAL] How the Planner in PGStrom differs from PostgreSQL?

On Thu, Nov 17, 2016 at 7:09 PM, Mark Anns wrote: > Can u explain this statement "check whether the scan qualifier can > be executable on GPU device" > > What are the scan qualifiers? > > How to determine whether they are device executable or not? > > The cost estimates

Re: [GENERAL] pg_class (system) table increasing size.

On 11/16/2016 07:08 PM, dhaval jaiswal wrote: Because you are creating (specific) objects. I have gone through the link and how would i figure out which specific object is causing this. Can you please elaborate more here. We do not have the much temporary table usage. Since the size is

Re: [GENERAL] pg_class (system) table increasing size.

On 11/16/2016 07:08 PM, dhaval jaiswal wrote: Because you are creating (specific) objects. I have gone through the link and how would i figure out which specific object is causing this. Can you please elaborate more here. It is not any one object, it is the total of the

Re: [GENERAL] libpq backwards compatbility

Thanks for the response. I have to also ask about binary compatibility in the other direction. I.e. An application compiled against 9.6 libpq headers but running against the 9.3 libpq library. Obviously you'd never choose to deploy this way in general, but we're not using any new libpq

Re: [GENERAL] How the Planner in PGStrom differs from PostgreSQL?

Can u explain this statement "check whether the scan qualifier can be executable on GPU device" What are the scan qualifiers? How to determine whether they are device executable or not? The cost estimates are entirely based on number of rows and type of scan. Then it will be same for both CPU

Re: [GENERAL] How the Planner in PGStrom differs from PostgreSQL?

Can u explain this statement "check whether the scan qualifier can be executable on GPU device" What are the scan qualifiers? How to determine whether they are device executable or not? -- View this message in context:

Re: [GENERAL] Streaming replication failover/failback

On Wed, 16 Nov 2016 15:51:26 -0900 Israel Brewster wrote: > I've been playing around with streaming replication, and discovered that the > following series of steps *appears* to work without complaint: > > - Start with master on server A, slave on server B, replicating

Re: [GENERAL] Request to share information regarding deadlock in postgresql-9.3.6

Rethinking that > -Original Message- > From: pgsql-general-ow...@postgresql.org > [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Charles > Clavadetscher > Sent: Donnerstag, 17. November 2016 09:12 > To: 'Yogesh Sharma' ; 'John R Pierce' >

Re: [GENERAL] Request to share information regarding deadlock in postgresql-9.3.6

Hello > -Original Message- > From: pgsql-general-ow...@postgresql.org > [mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Yogesh Sharma > Sent: Donnerstag, 17. November 2016 08:31 > To: John R Pierce ; pgsql-general@postgresql.org > Subject: Re: [GENERAL]

Re: [GENERAL] pg_restore --clean failing due to dependancies

Le 16/11/2016 à 20:05, Tom Lane a écrit : Arnaud Lesauvage writes: [ dump from problematic database ] OK, thanks for the test case. The problem here is that pg_dump is setting up a circular dependency that it doesn't know how to break correctly. You've got a