public inbox for [email protected]  
help / color / mirror / Atom feed
[PATCH 1/8] introduce bsearch_arg
2+ messages / 2 participants
[nested] [flat]

* [PATCH 1/8] introduce bsearch_arg
@ 2021-03-04 23:16  Tomas Vondra <[email protected]>
  0 siblings, 0 replies; 2+ messages in thread

From: Tomas Vondra @ 2021-03-04 23:16 UTC (permalink / raw)

---
 src/backend/statistics/extended_stats.c       | 31 --------------
 src/include/port.h                            |  5 +++
 .../statistics/extended_stats_internal.h      |  5 ---
 src/port/Makefile                             |  1 +
 src/port/bsearch_arg.c                        | 40 +++++++++++++++++++
 5 files changed, 46 insertions(+), 36 deletions(-)
 create mode 100644 src/port/bsearch_arg.c

diff --git a/src/backend/statistics/extended_stats.c b/src/backend/statistics/extended_stats.c
index a030ea3653..fa42851fd5 100644
--- a/src/backend/statistics/extended_stats.c
+++ b/src/backend/statistics/extended_stats.c
@@ -659,37 +659,6 @@ compare_datums_simple(Datum a, Datum b, SortSupport ssup)
 	return ApplySortComparator(a, false, b, false, ssup);
 }
 
-/* simple counterpart to qsort_arg */
-void *
-bsearch_arg(const void *key, const void *base, size_t nmemb, size_t size,
-			int (*compar) (const void *, const void *, void *),
-			void *arg)
-{
-	size_t		l,
-				u,
-				idx;
-	const void *p;
-	int			comparison;
-
-	l = 0;
-	u = nmemb;
-	while (l < u)
-	{
-		idx = (l + u) / 2;
-		p = (void *) (((const char *) base) + (idx * size));
-		comparison = (*compar) (key, p, arg);
-
-		if (comparison < 0)
-			u = idx;
-		else if (comparison > 0)
-			l = idx + 1;
-		else
-			return (void *) p;
-	}
-
-	return NULL;
-}
-
 /*
  * build_attnums_array
  *		Transforms a bitmap into an array of AttrNumber values.
diff --git a/src/include/port.h b/src/include/port.h
index 227ef4b148..82f63de325 100644
--- a/src/include/port.h
+++ b/src/include/port.h
@@ -508,6 +508,11 @@ typedef int (*qsort_arg_comparator) (const void *a, const void *b, void *arg);
 extern void qsort_arg(void *base, size_t nel, size_t elsize,
 					  qsort_arg_comparator cmp, void *arg);
 
+extern void *bsearch_arg(const void *key, const void *base,
+						 size_t nmemb, size_t size,
+						 int (*compar) (const void *, const void *, void *),
+						 void *arg);
+
 /* port/chklocale.c */
 extern int	pg_get_encoding_from_locale(const char *ctype, bool write_message);
 
diff --git a/src/include/statistics/extended_stats_internal.h b/src/include/statistics/extended_stats_internal.h
index c849bd57c0..a0a3cf5b0f 100644
--- a/src/include/statistics/extended_stats_internal.h
+++ b/src/include/statistics/extended_stats_internal.h
@@ -85,11 +85,6 @@ extern int	multi_sort_compare_dims(int start, int end, const SortItem *a,
 extern int	compare_scalars_simple(const void *a, const void *b, void *arg);
 extern int	compare_datums_simple(Datum a, Datum b, SortSupport ssup);
 
-extern void *bsearch_arg(const void *key, const void *base,
-						 size_t nmemb, size_t size,
-						 int (*compar) (const void *, const void *, void *),
-						 void *arg);
-
 extern AttrNumber *build_attnums_array(Bitmapset *attrs, int *numattrs);
 
 extern SortItem *build_sorted_items(int numrows, int *nitems, HeapTuple *rows,
diff --git a/src/port/Makefile b/src/port/Makefile
index e41b005c4f..52dbf5783f 100644
--- a/src/port/Makefile
+++ b/src/port/Makefile
@@ -40,6 +40,7 @@ LIBS += $(PTHREAD_LIBS)
 OBJS = \
 	$(LIBOBJS) \
 	$(PG_CRC32C_OBJS) \
+	bsearch_arg.o \
 	chklocale.o \
 	erand48.o \
 	inet_net_ntop.o \
diff --git a/src/port/bsearch_arg.c b/src/port/bsearch_arg.c
new file mode 100644
index 0000000000..d24dc4b7c4
--- /dev/null
+++ b/src/port/bsearch_arg.c
@@ -0,0 +1,40 @@
+/*
+ *	bsearch_arg.c: bsearch variant with a user-supplied pointer
+ *
+ *	src/port/bsearch_arg.c
+ */
+
+
+#include "c.h"
+
+
+/* simple counterpart to qsort_arg */
+void *
+bsearch_arg(const void *key, const void *base, size_t nmemb, size_t size,
+			int (*compar) (const void *, const void *, void *),
+			void *arg)
+{
+	size_t		l,
+				u,
+				idx;
+	const void *p;
+	int			comparison;
+
+	l = 0;
+	u = nmemb;
+	while (l < u)
+	{
+		idx = (l + u) / 2;
+		p = (void *) (((const char *) base) + (idx * size));
+		comparison = (*compar) (key, p, arg);
+
+		if (comparison < 0)
+			u = idx;
+		else if (comparison > 0)
+			l = idx + 1;
+		else
+			return (void *) p;
+	}
+
+	return NULL;
+}
-- 
2.26.2


--------------82D677E9F94AC7574E460205
Content-Type: text/x-patch; charset=UTF-8;
 name="0002-Pass-all-scan-keys-to-BRIN-consistent-funct-20210308.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0002-Pass-all-scan-keys-to-BRIN-consistent-funct-20210308.pa";
 filename*1="tch"



^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Sort optimizations: Making in-memory sort cache-aware
@ 2023-02-11 12:19  Ankit Kumar Pandey <[email protected]>
  0 siblings, 0 replies; 2+ messages in thread

From: Ankit Kumar Pandey @ 2023-02-11 12:19 UTC (permalink / raw)
  To: pghackers <[email protected]>; David Rowley <[email protected]>

Hi all,

While working on sort optimization for window function, it was seen that 
performance of sort where

all tuples are in memory was bad when number of tuples were very large [1]

Eg: work_mem = 4 GB, sort on 4 int columns on table having 10 million 
tuples.


Issues we saw were as follows:

1. The comparetup function re-compares the first key again in case of 
tie-break.

2. Frequent cache misses


Issue #1 is being looked in separate patch. I am currently looking at #2.

Possible solution was to batch tuples into groups (which can fit into L3 
cache) before pushing them to sort function.

After looking at different papers on this (multi-Quicksort, memory-tuned 
quicksort, Samplesort and various distributed sorts),

although they look promising (especially samplesort), I would like to 
get more inputs as changes look bit too steep and

may or may not be in of scope of solving actual problem in hand.


Please let me know your opinions, do we really need to re-look at 
quicksort for this use-case or we can

perform optimization without major change in core sorting algorithm? Are 
we are open for trying new algorithms for sort?

Any suggestions to narrow down search space for this problem are welcomed.


[1] 
https://www.postgresql.org/message-id/[email protected]...


Thanks,

Ankit







^ permalink  raw  reply  [nested|flat] 2+ messages in thread


end of thread, other threads:[~2023-02-11 12:19 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-03-04 23:16 [PATCH 1/8] introduce bsearch_arg Tomas Vondra <[email protected]>
2023-02-11 12:19 Sort optimizations: Making in-memory sort cache-aware Ankit Kumar Pandey <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox