On Fri, Jun 17, 2016 at 1:09 AM, julyanto SUTANDANG
wrote:
> This way is doing faster using crc32(data) than hashtext since crc32 is
> hardware accelerated in intel (and others perhaps)
> this way (crc32) is no way the same as hash, much way faster than others...
>
> Regards,
Sure, but I've had
This way is doing faster using crc32(data) than hashtext since crc32 is
hardware accelerated in intel (and others perhaps)
this way (crc32) is no way the same as hash, much way faster than
others...
Regards,
On Fri, Jun 17, 2016 at 10:51 AM, Claudio Freire
wrote:
> On Wed, Jun 15, 2016 at 6:3
It'd be really hard to get a test dataset together I think, so I suppose
i'll learn how to compile Postgres. Will let you know how that goes.
Adam Brusselback writes:
> Alright with that off I get:
> ...
> Way better.
OK, that confirms the suspicion that beta1's FK-join-estimation logic
is the culprit here. We had already decided that that logic is broken,
and there's a rewrite in progress:
https://www.postgresql.org/message-id/15245.
On Wed, Jun 15, 2016 at 6:34 AM, Ivan Voras wrote:
>
> I have an application which stores a large amounts of hex-encoded hash
> strings (nearly 100 GB of them), which means:
>
> The number of distinct characters (alphabet) is limited to 16
> Each string is of the same length, 64 characters
> The s
Alright with that off I get:
'Nested Loop Anti Join (cost=25.76..21210.81 rows=16684 width=106) (actual
time=0.688..249.585 rows=26994 loops=1)'
' -> Hash Join (cost=25.34..7716.95 rows=21906 width=106) (actual
time=0.671..124.663 rows=28467 loops=1)'
'Hash Cond: (cp.claim_id = x.claim
Adam Brusselback writes:
> Gah, hit send too soon...
Hm, definitely a lot of foreign keys in there. Do the estimates get
better (or at least closer to 9.5) if you do
"set enable_fkey_estimates = off"?
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql
Gah, hit send too soon...
CREATE TEMPORARY TABLE _claims_to_process ( claim_id uuid, starting_state
enum.claim_state );
CREATE TABLE claim_product
(
claim_product_id uuid NOT NULL DEFAULT gen_random_uuid(),
claim_id uuid NOT NULL,
product_id uuid NOT NULL,
uom_type_id uuid NOT NULL,
reb
I analyzed all tables involved after loading, and also while trying to
diagnose this issue.
I have the same statistics target settings on both servers.
Here are the schemas for the tables:
On Thu, Jun 16, 2016 at 10:04 PM, Tom Lane wrote:
> Adam Brusselback writes:
> > Hey all, testing out 9.
Adam Brusselback writes:
> Hey all, testing out 9.6 beta 1 right now on Debian 8.5.
> I have a query that is much slower on 9.6 than 9.5.3.
The rowcount estimates in 9.6 seem way off. Did you ANALYZE the tables
after loading them into 9.6? Maybe you forgot some statistics target
settings?
If i
Hey all, testing out 9.6 beta 1 right now on Debian 8.5.
I have a query that is much slower on 9.6 than 9.5.3.
As a side note, when I explain analyze instead of just executing the query
it takes more than 2x as long to run. I have tried looking for info on that
online but have not found any. Any
On Thu, Jun 16, 2016 at 11:05 AM, Tom Lane wrote:
> meike.talb...@women-at-work.org writes:
> > When I query this through pgsql, the queries are fast as expected.
> > select * from push_topic where guid =
> 'DD748CCD-B8A4-3B9F-8F60-67F1F673CFE5'
> > Index Scan using push_topic_idx_topicguid on pu
meike.talb...@women-at-work.org writes:
> When I query this through pgsql, the queries are fast as expected.
> select * from push_topic where guid = 'DD748CCD-B8A4-3B9F-8F60-67F1F673CFE5'
> Index Scan using push_topic_idx_topicguid on push_topic (cost=0.42..8.44
> rows=1 width=103) (actual time=0
When you run psql, are you running that on the application server or the
database server? Does the application run on the same server as the database
and how is the application connecting to the database (JDBC, ODBC, etc)?
In other words is there a difference in network time between the 2?
Also
When you create an Postgres RDS instance, it's comes with a
"default.postgres9.3" parameter group which contains substitutions based on
the server size. The defaults for the memory related settings are:
effective_cache_size = {DBInstanceClassMemory/16384}
maintenance_work_mem = GREATEST({DBInstanc
Hello,
I've a basic table with about 100K rows:
CREATE TABLE "public"."push_topic" (
"id" Serial PRIMARY KEY,
"guid" public.push_guid NOT NULL,
"authenticatorsending" Varchar(32) NOT NULL,
"authenticatorsubscription" Varchar(32) NOT NULL,
"countpushed" Integer NOT NULL,
"datecreated" ti
16 matches
Mail list logo
