Services
24×7×365 Technical Support
Migration to PostgreSQL
High Availability Deployment
Database Audit
Remote DBA for PostgreSQL
Products
Postgres Pro Enterprise
Postgres Pro Standard
Cloud Solutions
Postgres Extensions
Resources
Blog
Documentation
Webinars
Videos
Presentations
Community
Events
Training Courses
Books
Demo Database
Mailing List Archives
About
Leadership team
Partners
Customers
In the News
Press Releases
Press Info
Services
24×7×365 Technical Support
Migration to PostgreSQL
High Availability Deployment
Database Audit
Remote DBA for PostgreSQL
Products
Postgres Pro Enterprise
Postgres Pro Standard
Cloud Solutions
Postgres Extensions
Resources
Blog
Documentation
Webinars
Videos
Presentations
Community
Events
Training Courses
Books
Demo Database
Mailing List Archives
About
Leadership team
Partners
Customers
In the News
Press Releases
Press Info
Facebook
Downloads
Home
>
mailing lists
Re: Using quicksort for every external sort run - Mailing list pgsql-hackers
From
Mithun Cy
Subject
Re: Using quicksort for every external sort run
Date
January 29, 2016
14:41:38
Msg-id
CAD__OuhgUbZgszr-Ftf=bqgz-YwD60T5xMOikvXYiBQUCNpPqQ@mail.gmail.com
Whole thread
Raw
In response to
Re: Using quicksort for every external sort run
(Peter Geoghegan <pg@heroku.com>)
Responses
Re: Using quicksort for every external sort run
(Mithun Cy <mithun.cy@enterprisedb.com>)
Re: Using quicksort for every external sort run
(Peter Geoghegan <pg@heroku.com>)
List
pgsql-hackers
Tree view
On Tue, Dec 29, 2015 at 4:33 AM, Peter Geoghegan
<
pg@heroku.com
>
wrote:
>Attached is a revision that significantly overhauls the memory patch,
>with several smaller changes.
I just ran some tests on above patch. Mainly to compare
how "longer sort keys" would behave with new(Qsort) and old Algo(RS) for sorting.
I have 8GB of ram and ssd storage.
Settings and Results.
----------------------------
Work_mem= DEFAULT (4mb).
key width = 520.
CASE 1. Data is pre-sorted as per sort key order.
CASE 2. Data is sorted in opposite order of sort key.
CASE 3. Data is randomly distributed.
Key length 520
Number of records
3200000
6400000
12800000
25600000
1.7 GB
3.5GB
7 GB
14GB
CASE 1
RS
23654.677
35172.811
44965.442
106420.155
Qsort
14100.362
40612.829
101068.107
334893.391
CASE 2
RS
13427.378
36882.898
98492.644
310670.15
Qsort
12475.133
32559.074
100772.531
322080.602
CASE 3
RS
17202.966
45163.234
122323.299
337058.856
Qsort
12530.726
23343.753
59431.315
152862.837
If data is sorted as same as sort key order then current code performs better than proposed patch
as sort size increases.
It appears new algo do not seem have any major impact if rows are presorted in opposite order.
For randomly distributed order quick sort performs well when compared to current sort method (RS).
======================================================
Now Increase the work_mem to 64MB and for 14 GB of data to sort.
CASE 1: We can see Qsort is able to catchup with current sort method(RS).
CASE 2: No impact.
CASE 3: RS is able to catchup with Qsort.
CASE 1
RS
128822.735
Qsort
90857.496
CSAE 2
RS
105631.775
Qsort
105938.334
CASE 3
RS
152301.054
Qsort
149649.347
I think for long keys both old (RS) and new (Qsort) sort method has its own characteristics
based on data distribution. I think work_mem is the key If properly set new method(Qsort) will
be able to fit most of the cases. If work_mem is not tuned right it, there are cases it can regress.
--
Thanks and Regards
Mithun C Y
EnterpriseDB:
http://www.enterprisedb.com
Attachment
Test Queries.sql
pgsql-hackers
by date:
Previous
From:
Oleg Bartunov
Date:
29 January 2016, 14:15:47
Subject:
Re: Fuzzy substring searching with the pg_trgm extension
Next
From:
Alexander Korotkov
Date:
29 January 2016, 15:00:19
Subject:
Re: [PATCH] Refactoring of LWLock tranches
Есть вопросы? Напишите нам!
Соглашаюсь с условиями обработки персональных данных
I confirm that I have read and accepted PostgresPro’s
Privacy Policy
.
I agree to get Postgres Pro discount offers and other marketing communications.
✖
×
×
Everywhere
Documentation
Mailing list
List:
all lists
pgsql-general
pgsql-hackers
buildfarm-members
pgadmin-hackers
pgadmin-support
pgsql-admin
pgsql-advocacy
pgsql-announce
pgsql-benchmarks
pgsql-bugs
pgsql-chat
pgsql-cluster-hackers
pgsql-committers
pgsql-cygwin
pgsql-docs
pgsql-hackers-pitr
pgsql-hackers-win32
pgsql-interfaces
pgsql-jdbc
pgsql-jobs
pgsql-novice
pgsql-odbc
pgsql-patches
pgsql-performance
pgsql-php
pgsql-pkg-debian
pgsql-pkg-yum
pgsql-ports
pgsql-rrreviewers
pgsql-ru-general
pgsql-sql
pgsql-students
pgsql-testers
pgsql-translators
pgsql-www
psycopg
Period
anytime
within last day
within last week
within last month
within last 6 months
within last year
Sort by
date
reverse date
rank
Services
24×7×365 Technical Support
Migration to PostgreSQL
High Availability Deployment
Database Audit
Remote DBA for PostgreSQL
Products
Postgres Pro Enterprise
Postgres Pro Standard
Cloud Solutions
Postgres Extensions
Resources
Blog
Documentation
Webinars
Videos
Presentations
Community
Events
Training Courses
Books
Demo Database
Mailing List Archives
About
Leadership team
Partners
Customers
In the News
Press Releases
Press Info
By continuing to browse this website, you agree to the use of cookies. Go to
Privacy Policy
.
I accept cookies