| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | maxim(dot)boguk(at)gmail(dot)com | 
| Cc: | pgsql-bugs(at)postgresql(dot)org | 
| Subject: | Re: BUG #12866: Another performance problem with intarray extenstion operators | 
| Date: | 2015-03-15 17:20:11 | 
| Message-ID: | 28555.1426440011@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-bugs | 
maxim(dot)boguk(at)gmail(dot)com writes:
> I found second case where intarray operators have serious performance
> issues:
> ...
> PS: filling array in descending order is critical to reproducing the issue.
The problem is evidently in isort():
	/*
	 * We use a simple insertion sort.  While this is O(N^2) in the worst
	 * case, it's quite fast if the input is already sorted or nearly so.
	 * Also, for not-too-large inputs it's faster than more complex methods
	 * anyhow.
	 */
That comment, as well as the current code, date to my commit fdf2dbda;
but it doesn't look like the previous code was any better in terms of
worst-case behavior.  It's tempting to just trash the whole thing in
favor of qsort().
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | lr | 2015-03-16 04:51:19 | BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch | 
| Previous Message | maxim.boguk | 2015-03-15 01:06:08 | BUG #12866: Another performance problem with intarray extenstion operators |