Re: [PERFORM] 9.6 query slower than 9.5.3

[Tom Lane]

Adam Brusselback  writes:
> I finally managed to get it compiled, patched, and working.  It gave the
> same plan with the same estimates as when I turned fkey_estimates off.

OK, well, at least it's not making things worse ;-).  But I think that
this estimation method isn't very helpful for antijoin cases anyway.

> I was wondering if I did things properly though, as i don't see the
> enable_fkey_estimates GUC any more. Was it removed?

Yes, that was only intended for debugging, and the consensus was that
it probably shouldn't have been committed in the first place.

Thanks for taking the trouble to check this!

regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

[PERFORM] Savepoint and Releasepoint in Logs

[e.ratnakar.shetty]

Hi ,

I am connecting to PostgreSQL 9.4 via an ODBC driver on Windows machine from MS 
VBA application. I am facing huge performance issues while inserting data 
continuously. On analysing the logs , there were around 9 statements 
related to Save Points and Release Points.

duration: 2.000 ms
2016-06-17 12:45:02 BST LOG:  statement: RELEASE _EXEC_SVP_1018CCF8
2016-06-17 12:45:02 BST LOG:  duration: 1.000 ms
2016-06-17 12:45:05 BST LOG:  statement: SAVEPOINT _EXEC_SVP_186EB5C8
2016-06-17 12:45:05 BST LOG:  duration: 0.000 ms

I am guessing these statements are causing an overhead while inserting records 
in to the table. Could you please let me know if I need to change any 
configuration settings to avoid creating any save points as the transaction is 
handled in the application.

Thanks

Regards,
Eisha Shetty
ACCENTURE | UK-NEWCASTLE
* +44 7741587433
* e.ratnakar.she...@accenture.com

This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the e-mail by you is prohibited. Where allowed by local law, electronic 
communications with Accenture and its affiliates, including e-mail and instant 
messaging (including content), may be scanned by our systems for the purposes 
of information security and assessment of internal compliance with Accenture 
policy.Accenture means Accenture (UK) Limited (registered number 4757301), 
registered in England and Wales with registered address at 30 Fenchurch Street, 
London EC3M 3BD.

Re: [PERFORM] 9.6 query slower than 9.5.3

[Adam Brusselback]

I finally managed to get it compiled, patched, and working.  It gave the
same plan with the same estimates as when I turned fkey_estimates off.

I was wondering if I did things properly though, as i don't see the
enable_fkey_estimates GUC any more. Was it removed?

Re: [PERFORM] Indexes for hashes

[julyanto SUTANDANG]

Crc32 is great because it is supported by Intel Hardware, unfortunatelly
you have to code something like this:

http://stackoverflow.com/questions/31184201/how-to-implement-crc32-taking-advantage-of-intel-specific-instructions


int32_t sse42_crc32(const uint8_t *bytes, size_t len){
  uint32_t hash = 0;
  size_t i = 0;
  for (i=0;i wrote:

> And in any case, there's no crc32 in the built-in pgcrypto module.
>
>
> On 17 June 2016 at 06:18, Claudio Freire  wrote:
>
>> 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 uniformity issues with crc32.
>>
>
>


-- 


Julyanto SUTANDANG

Equnix Business Solutions, PT
(An Open Source an Open Mind Company)

Pusat Niaga ITC Roxy Mas Blok C2/42.  Jl. KH Hasyim Ashari 125, Jakarta
Pusat
T: +6221 2282 F: +62216315281 M: +628164858028


Caution: The information enclosed in this email (and any attachments) may
be legally privileged and/or confidential and is intended only for the use
of the addressee(s). No addressee should forward, print, copy, or otherwise
reproduce this message in any manner that would allow it to be viewed by
any individual not originally listed as a recipient. If the reader of this
message is not the intended recipient, you are hereby notified that any
unauthorized disclosure, dissemination, distribution, copying or the taking
of any action in reliance on the information herein is strictly prohibited.
If you have received this communication in error, please immediately notify
the sender and delete this message.Unless it is made by the authorized
person, any views expressed in this message are those of the individual
sender and may not necessarily reflect the views of PT Equnix Business
Solutions.

Re: [PERFORM] Indexes for hashes

[Ivan Voras]

And in any case, there's no crc32 in the built-in pgcrypto module.


On 17 June 2016 at 06:18, Claudio Freire  wrote:

> 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 uniformity issues with crc32.
>