"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.
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
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 w
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 autovacuum
> to vacuum the table
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
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| 1838
> seq_tup_read
> 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
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 | 9
> 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 tablespace and I don't understand why. An "ls $PGDATA/ourd
On Nov 16, 2016, at 11:39 PM, Jehan-Guillaume de Rorthais
wrote:
>
> On Wed, 16 Nov 2016 15:51:26 -0900
> Israel Brewster mailto:isr...@ravnalaska.net>> wrote:
>
>> I've been playing around with streaming replication, and discovered that the
>> following series of steps *appears* to work withou
> 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 with master on server A, slave
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
> files are still present. A
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 post
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 are entirely based on numb
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
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 objects(relations)
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 features
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 a
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:
http://postgresql.nabble.com/How-the-Planner-in-PGStrom-differs-from-Postg
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 via streaming
> replicatio
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'
> ; pgsql-
> gene...@postgresql.org
> Sub
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] Request to share informati
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 couple of views that are implicit
23 matches
Mail list logo