Re: [HACKERS] Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
- Цитат от David Fetter (da...@fetter.org), на 23.07.2012 в 15:41 - I'm not sure how you automate testing a pull-the-plug scenario. I have a dim memory of how the FreeBSD project was alleged to have done it, namely by rigging a serial port (yes, it was that long ago) to the power supply of another machine and randomly cycling the power. These days most of the server class hardware could be power-cycled with IPMI command. Best regards -- Luben Karavelov
Re: [HACKERS] libpq URL syntax vs SQLAlchemy
- Цитат от Alex Shulgin (a...@commandprompt.com), на 14.05.2012 в 18:16 - Alex a...@commandprompt.com writes: The host part in this case is empty (it is hidden between the // and the following /,) thus local socket connection is employed for this type of URIs. To specify non-standard path to the local sockets directory use the familiar URI parameter: postgres:///db?host=/path/to/socket/dir And why are we calling host the parameter that specifies the path for socket dir - it is not host and could be confused with the host part of the URI (the part between // and /). Why do not call it path ? So it will become: postgres:///db?path=/path/to/socket/dir Best regards -- Luben Karavelov
Re: [HACKERS] swapcache-style cache?
- Цитат от Andrea Suisani (sick...@opinioni.net), на 28.02.2012 в 09:54 - On 02/28/2012 04:52 AM, Rob Wultsch wrote: On Wed, Feb 22, 2012 at 2:31 PM, jamesja...@mansionfamily.plus.com wrote: Has anyone considered managing a system like the DragonFLY swapcache for a DBMS like PostgreSQL? https://www.facebook.com/note.php?note_id=388112370932 in the same vein: http://bcache.evilpiepirate.org/ from the main page: Bcache is a patch for the Linux kernel to use SSDs to cache other block devices. It's analogous to L2Arc for ZFS, but Bcache also does writeback caching, and it's filesystem agnostic. It's designed to be switched on with a minimum of effort, and to work well without configuration on any setup. By default it won't cache sequential IO, just the random reads and writes that SSDs excel at. It's meant to be suitable for desktops, servers, high end storage arrays, and perhaps even embedded. it was submitted to linux kernel mailing list a bunch of time, the last one: https://lkml.org/lkml/2011/9/10/13 Andrea I am successfully using facebook's flashchache in write-through mode - so it speeds only reads. I have seen 3 times increase on TPS for databases that do not fit in RAM. I am using Intel X-25E over RAID10 of 4 SAS disks. I have tested also writeback mode but the gain is not so huge and there is a considerable risk for loosing all your data if/when the SSD fails. Best regards -- Luben Karavelov
Re: [HACKERS] Initial 9.2 pgbench write results
- Цитат от Robert Haas (robertmh...@gmail.com), на 28.02.2012 в 19:25 - On Tue, Feb 28, 2012 at 11:36 AM, Jeff Janes jeff.ja...@gmail.com wrote: How hard would it be to dummy up a bgwriter which, every time it wakes up, it forks off a child process to actually do the write, and then the real one just waits for the child to exit? If it didn't have to correctly handle signals, SINVAL, and such, it should be just a few lines of code, but I don't know how much we can ignore signals and such even just for testing purposes. My thought here is that the kernel is getting in a snit over one process doing all the writing on the system, and is punishing that process in a way that ruins things for everyone. I would assume the only punishment that the kernel would inflict would be to put the bgwriter to sleep. That would make the bgwriter less effective, of course, but it shouldn't make it worse than no bgwriter at all. Unless it does it some really stupid way, like making bgwriter sleep while it holds some lock. But maybe I'm missing something - what do you have in mind? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Luben Karavelov
Re: [HACKERS] TS: Limited cover density ranking
- Цитат от Oleg Bartunov (o...@sai.msu.su), на 28.01.2012 в 21:04 -
I suggest you work on more general approach, see
http://www.sai.msu.su/~megera/wiki/2009-08-12 for example.
btw, I don't like you changed ts_rank_cd arguments.
Hello Oleg,
Thanks for the feedback.
Is it OK to begin with adding an exta argument and check in calc_rank_cd?
I could change the function names in order not to overload ts_rank_cd
arguments. My proposition is :
at sql level:
ts_rank_lcd([weights], tsvector, tsquery, limit, [method])
at C level:
ts_ranklcd_wttlf
ts_ranklcd_wttl
ts_ranklcd_ttlf
ts_ranklcd_ttl
Adding the functions could be done as an extension but they are just
trampolines into calc_rank_cd().
I agree that what you describe in the wiki page is more general approach. So
this :
SELECT ts_rank_lcd(to_tsvector('a b c'), to_tsquery('ac'),2 )0;
could be replaced with
SELECT to_tsvector('a b c') @@ to_tsquery('(a ?2 c)|(c ?2 a) ');
but if we need to look for 3 or more nearby terms without order the tsquery
with '?' operator will became quite complicated. For example
SELECT tsvec @@
'(a ? b ? c) | (a ? c ? b) | (b ? a ? c) | (b ? c ? a) | (c ? a ? b) | (c ? b ?
a)'::tsquery;
is the same as
SELECT ts_rank_lcd(tsvec, 'abc'::tsquery,2)0;
So this is the reason to think that the general approach does not exclude the
the
usefulness of the approach that I am proposing.
Best regards
--
Luben Karavelov
[HACKERS] TS: Limited cover density ranking
Hello,
I have developed a variation of cover density ranking functions that counts
only covers that are lesser than a specified limit. It is useful for finding
combinations of terms that appear nearby one another. Here is an example of
usage:
-- normal cover density ranking : not changed
luben= select ts_rank_cd(to_tsvector('a b c d e g h i j k'),
to_tsquery('ad'));
ts_rank_cd
0.033
(1 row)
-- limited to 2
luben= select ts_rank_cd(2, to_tsvector('a b c d e g h i j k'),
to_tsquery('ad'));
ts_rank_cd
0
(1 row)
luben= select ts_rank_cd(2, to_tsvector('a b c d e g h i j k a d'),
to_tsquery('ad'));
ts_rank_cd
0.1
(1 row)
-- limited to 3
luben= select ts_rank_cd(3, to_tsvector('a b c d e g h i j k'),
to_tsquery('ad'));
ts_rank_cd
0.033
(1 row)
luben= select ts_rank_cd(3, to_tsvector('a b c d e g h i j k a d'),
to_tsquery('ad'));
ts_rank_cd
0.13
(1 row)
Find attached a path agains 9.1.2 sources. I preferred to make a patch, not a
separate extension because it is only 1 statement change in calc_rank_cd
function. If I have to make an extension a lot of code would be duplicated
between backend/utils/adt/tsrank.c and the extension.
I have some questions:
1. Is it interesting to develop it further (documentation, cleanup, etc) for
inclusion in one of the next versions? If this is the case, there are some
further questions:
- should I overload ts_rank_cd (as in examples above and the patch) or should I
define new set of functions, for example ts_rank_lcd ?
- should I define define this new sql level functions in core or should I go
only with this 2 lines change in calc_rank_cd() and define the new functions as
an extension? If we prefer the later, could I overload core functions with
functions defined in extensions?
- and finally there is always the possibility to duplicate the code and make an
independent extension.
2. If I run the patched version on cluster that was initialized with unpatched
server, is there a way to register the new functions in the system catalog
without reinitializing the cluster?
Best regards
luben
--
Luben Karavelov
Re: [HACKERS] TS: Limited cover density ranking
And here is the patch, that I forgot to attach
Hello,
I have developed a variation of cover density ranking functions that counts
only covers that are lesser than a specified limit. It is useful for finding
combinations of terms that appear nearby one another. Here is an example of
usage:
...
Find attached a path agains 9.1.2 sources. I preferred to make a patch, not a
separate extension because it is only 1 statement change in calc_rank_cd
function. If I have to make an extension a lot of code would be duplicated
between backend/utils/adt/tsrank.c and the extension.
--
Luben Karavelovdiff -pur postgresql-9.1-9.1.2/src/backend/utils/adt/tsrank.c /usr/src/postgresql-9.1-9.1.2/src/backend/utils/adt/tsrank.c
--- postgresql-9.1-9.1.2/src/backend/utils/adt/tsrank.c 2011-12-01 23:47:20.0 +0200
+++ /usr/src/postgresql-9.1-9.1.2/src/backend/utils/adt/tsrank.c 2012-01-27 07:45:34.558028176 +0200
@@ -724,7 +724,7 @@ get_docrep(TSVector txt, QueryRepresenta
}
static float4
-calc_rank_cd(float4 *arrdata, TSVector txt, TSQuery query, int method)
+calc_rank_cd(int limit, float4 *arrdata, TSVector txt, TSQuery query, int method)
{
DocRepresentation *doc;
int len,
@@ -768,6 +768,9 @@ calc_rank_cd(float4 *arrdata, TSVector t
int nNoise;
DocRepresentation *ptr = ext.begin;
+if (limit 0 ext.end-pos - ext.begin-pos limit)
+continue;
+
while (ptr = ext.end)
{
InvSum += invws[ptr-wclass];
@@ -834,7 +837,7 @@ ts_rankcd_wttf(PG_FUNCTION_ARGS)
int method = PG_GETARG_INT32(3);
float res;
- res = calc_rank_cd(getWeights(win), txt, query, method);
+ res = calc_rank_cd(0, getWeights(win), txt, query, method);
PG_FREE_IF_COPY(win, 0);
PG_FREE_IF_COPY(txt, 1);
@@ -850,7 +853,7 @@ ts_rankcd_wtt(PG_FUNCTION_ARGS)
TSQuery query = PG_GETARG_TSQUERY(2);
float res;
- res = calc_rank_cd(getWeights(win), txt, query, DEF_NORM_METHOD);
+ res = calc_rank_cd(0, getWeights(win), txt, query, DEF_NORM_METHOD);
PG_FREE_IF_COPY(win, 0);
PG_FREE_IF_COPY(txt, 1);
@@ -866,7 +869,7 @@ ts_rankcd_ttf(PG_FUNCTION_ARGS)
int method = PG_GETARG_INT32(2);
float res;
- res = calc_rank_cd(getWeights(NULL), txt, query, method);
+ res = calc_rank_cd(0, getWeights(NULL), txt, query, method);
PG_FREE_IF_COPY(txt, 0);
PG_FREE_IF_COPY(query, 1);
@@ -880,9 +883,75 @@ ts_rankcd_tt(PG_FUNCTION_ARGS)
TSQuery query = PG_GETARG_TSQUERY(1);
float res;
- res = calc_rank_cd(getWeights(NULL), txt, query, DEF_NORM_METHOD);
+ res = calc_rank_cd(0, getWeights(NULL), txt, query, DEF_NORM_METHOD);
PG_FREE_IF_COPY(txt, 0);
PG_FREE_IF_COPY(query, 1);
PG_RETURN_FLOAT4(res);
}
+
+Datum
+ts_rankcd_lwttf(PG_FUNCTION_ARGS)
+{
+int limit = PG_GETARG_INT32(0);
+ ArrayType *win = (ArrayType *) PG_DETOAST_DATUM(PG_GETARG_DATUM(1));
+ TSVector txt = PG_GETARG_TSVECTOR(2);
+ TSQuery query = PG_GETARG_TSQUERY(3);
+ int method = PG_GETARG_INT32(4);
+ float res;
+
+ res = calc_rank_cd(limit, getWeights(win), txt, query, method);
+
+ PG_FREE_IF_COPY(win, 1);
+ PG_FREE_IF_COPY(txt, 2);
+ PG_FREE_IF_COPY(query, 3);
+ PG_RETURN_FLOAT4(res);
+}
+
+Datum
+ts_rankcd_lwtt(PG_FUNCTION_ARGS)
+{
+int limit = PG_GETARG_INT32(0);
+ ArrayType *win = (ArrayType *) PG_DETOAST_DATUM(PG_GETARG_DATUM(1));
+ TSVector txt = PG_GETARG_TSVECTOR(2);
+ TSQuery query = PG_GETARG_TSQUERY(3);
+ float res;
+
+ res = calc_rank_cd(limit, getWeights(win), txt, query, DEF_NORM_METHOD);
+
+ PG_FREE_IF_COPY(win, 1);
+ PG_FREE_IF_COPY(txt, 2);
+ PG_FREE_IF_COPY(query, 3);
+ PG_RETURN_FLOAT4(res);
+}
+
+Datum
+ts_rankcd_lttf(PG_FUNCTION_ARGS)
+{
+int limit = PG_GETARG_INT32(0);
+ TSVector txt = PG_GETARG_TSVECTOR(1);
+ TSQuery query = PG_GETARG_TSQUERY(2);
+ int method = PG_GETARG_INT32(3);
+ float res;
+
+ res = calc_rank_cd(limit, getWeights(NULL), txt, query, method);
+
+ PG_FREE_IF_COPY(txt, 1);
+ PG_FREE_IF_COPY(query, 2);
+ PG_RETURN_FLOAT4(res);
+}
+
+Datum
+ts_rankcd_ltt(PG_FUNCTION_ARGS)
+{
+int limit = PG_GETARG_INT32(0);
+ TSVector txt = PG_GETARG_TSVECTOR(1);
+ TSQuery query = PG_GETARG_TSQUERY(2);
+ float res;
+
+ res = calc_rank_cd(limit, getWeights(NULL), txt, query, DEF_NORM_METHOD);
+
+ PG_FREE_IF_COPY(txt, 1);
+ PG_FREE_IF_COPY(query, 2);
+ PG_RETURN_FLOAT4(res);
+}
diff -pur postgresql-9.1-9.1.2/src/include/catalog/pg_proc.h /usr/src/postgresql-9.1-9.1.2/src/include/catalog/pg_proc.h
--- postgresql-9.1-9.1.2/src/include/catalog/pg_proc.h 2011-12-01 23:47:20.0 +0200
+++ /usr/src/postgresql-9.1-9.1.2/src/include/catalog/pg_proc.h 2012-01-27 05:45:53.944979678 +0200
@@ -4159,6 +4159,15 @@ DATA(insert OID = 3709 ( ts_rank_cd PGN
DESCR(relevance);
DATA(insert OID = 3710 ( ts_rank_cd PGNSP PGUID 12 1 0 0 f f f t f i 2 0 700 3614 3615 _null_ _null_ _null_ _null_ ts_rankcd_tt _null_ _null_ _null_ ));
DESCR(relevance);
+DATA(insert OID = 3675 ( ts_rank_cd PGNSP PGUID 12 1 0 0 f f f t f i 5 0 700 23 1021 3614
Re: [HACKERS] TS: Limited cover density ranking
- Цитат от Sushant Sinha (sushant...@gmail.com), на 27.01.2012 в 18:32 -
The rank counts 1/coversize. So bigger covers will not have much impact
anyway. What is the need of the patch?
-Sushant.
If you want to find only combinations of words that are close one to another,
with the patch you could use something as:
WITH a AS (SELECT to_tsvector('a b c d e g h i j k') AS vec, to_tsquery('ad')
AS query)
SELECT * FROM a WHERE vec @@ query AND ts_rank_cd(3,vec,query)0;
I could not find another way to make this type of queries. If there is an
alternative, I am open to suggestions
Best regards
--
Luben Karavelov
Re: [HACKERS] TS: Limited cover density ranking
- Цитат от karave...@mail.bg, на 27.01.2012 в 18:48 -
- Цитат от Sushant Sinha (sushant...@gmail.com), на 27.01.2012 в 18:32
-
The rank counts 1/coversize. So bigger covers will not have much impact
anyway. What is the need of the patch?
-Sushant.
If you want to find only combinations of words that are close one to another,
with the patch you could use something as:
WITH a AS (SELECT to_tsvector('a b c d e g h i j k') AS vec,
to_tsquery('ad') AS query)
SELECT * FROM a WHERE vec @@ query AND ts_rank_cd(3,vec,query)0;
Another example, if you want to match 'b c d' only, you could use:
WITH A AS (SELECT to_tsvector('a b c d e g h i j k') AS vec,
to_tsquery('bcd') AS query)
SELECT * FROM A WHERE vec @@ query AND ts_rank_cd(2,vec,query)0;
The catch is that it will match also 'b d c', 'd c b', 'd b c', 'c d b' and 'd
b d', so it is not a
replacement for exact phrase match but something that I find useful
--
Luben Karavelov
Re: [HACKERS] Why so few built-in range types?
- Цитат от Tom Lane (t...@sss.pgh.pa.us), на 02.12.2011 в 05:21 -
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 1, 2011 at 7:56 PM, Stephen Frost sfr...@snowman.net wrote:
I don't have any particular care about if cidr has indexing support or
not. I'm certainly not *against* it, except insofar as it encourages
use of a data type that really could probably be better (by being more
like ip4r..).
Not that you're biased or anything! :-p
IIRC, a lot of the basic behavior of the inet/cidr types was designed by
Paul Vixie (though he's not to blame for their I/O presentation).
So I'm inclined to doubt that they're as broken as Stephen claims.
regards, tom lane
I have looked at ip4r README file and my use of the extension. According to
the README, the main reasons for ip4r to exist are:
1. No index support for buildin datatypes.
2. They are variable width datatypes, because inet/cidr supports IPv6.
3. Semantic overloading - no random ranges, you could combine IP addr and
netmask in inet datatype.
What I have found in my experience is that the semantics of inet/cidr is what
you need in order to model IP networks - interfaces, addresses, routing tables,
bgp sessions, LIR databases etc. In this regard the main semantic shortcommings
of ip4r datatype are:
1. It could not represent address asignments. For example:
ip4r('10.0.0.1/24') is invalid. You sould represent it with two ip4r fields -
ip4r('10.0.0.1')
for the address and ip4r('10.0.0.0/24') for the net. Using build-in datatypes it
could be represented as inet('10.0.0.1/24')
2. You could have ip4r random ranges that could not exests in the IP network
stack of
any device. Eg. you could not configure route as 10.0.0.2-10.0.0.6
3. No IPv6 support.
So, from my viewpoint the semantic overloading of inet type is what you want
because
it represents the semantics of IP networks.
Best regards
--
Luben Karavelov
Re: [HACKERS] Why so few built-in range types?
- Цитат от Stephen Frost (sfr...@snowman.net), на 01.12.2011 в 15:56 - * Robert Haas (robertmh...@gmail.com) wrote: On Wed, Nov 30, 2011 at 3:58 PM, Stephen Frost sfr...@snowman.net wrote: Erm, isn't there a contrib type that already does all that for you..? ip4r or whatever? Just saying, if you're looking for that capability.. Oh, huh, good to know. Still, I'm not sure why you need to load a separate type to get this... there's no reason why the built-in CIDR type couldn't support it. The semantics of that type aren't what people actually want and there's been push-back about changing it due to backwards compatibility, etc. That's my recollection of the situation, anyway. I'm sure there's all kinds of fun talk in the archives about it. I have reached one or two times to use build-in inet/cidr types but the lack of indexing support for contains op was stopping me - i have used ip4r extension. I do not think that adding index support to a datatype classifies as semantic change that will break backward compatibility. Best regards -- Luben Karavelov
Re: [HACKERS] So, is COUNT(*) fast now?
- Цитат от Tom Lane (t...@sss.pgh.pa.us), на 22.10.2011 в 19:19 - Andres Freund and...@anarazel.de writes: On Saturday, October 22, 2011 05:20:26 PM Tom Lane wrote: Huh? In the case he's complaining about, the index is all in RAM. Sequentiality of access is not an issue (at least not at the page level --- within a page I suppose there could be cache-line effects). I was talking about L2/L3 caches... Yeah, but unless you think cache lines cross page boundaries (and we do take pains to align the buffers on 8K addresses), there's not going to be any sequentiality effect. Even if there were, it would only apply if the pages chanced to be adjacent in the buffer array, and there is no reason to expect that to be the case, for either seqscans or indexscans. regards, tom lane I worked on in-memory hash stables of parrot project. It is not the same as btrees but the structure and memory layout are not that different - tupples are going into pages etc. I have benchmarked iterating over such hash tables - sequential scan of the same table comes 20-30% faster than scan ordered by the hash value of the key. And this is overhead only of CPU cache lines - the numbers of instructions executed on the processor are pretty much the same (counted by valgrind). So I do think that if we have sequential scan of indexes (physical order) it will help even when all the data is in the buffercache. Best regards -- Luben Karavelov
Re: [HACKERS] Inlining comparators as a performance optimisation
- Цитат от Peter Geoghegan (pe...@2ndquadrant.com), на 21.09.2011 в 02:53 - On 20 September 2011 03:51, Tom Lane t...@sss.pgh.pa.us wrote: Considering that -O2 is our standard optimization level, that observation seems to translate to this patch will be useless in practice. I think you had better investigate that aspect in some detail before spending more effort. I don't think that the fact that that happens is at all significant at this early stage, and it never even occurred to me that you'd think that it might be. I was simply disclosing a quirk of this POC patch. The workaround is probably to use a macro instead. For the benefit of those that didn't follow the other threads, the macro-based qsort implementation, which I found to perform significantly better than regular qsort(), runs like this on my laptop when I built at 02 with GCC 4.6 just now: C stdlib quick-sort time elapsed: 2.092451 seconds Inline quick-sort time elapsed: 1.587651 seconds Does *that* look attractive to you? I've attached source code of the program that produced these figures, which has been ported to C from C++. When I #define LARGE_SIZE 1, here's what I see: [peter@peter inline_compar_test]$ ./a.out C stdlib quick-sort time elapsed: 23.659411 seconds Inline quick-sort time elapsed: 18.470611 seconds Here, sorting with the function pointer/stdlib version takes about 1.28 times as long. In the prior test (with the smaller LARGE_SIZE), it took about 1.32 times as long. Fairly predictable, linear, and not to be sniffed at. The variance I'm seeing across runs is low - a couple of hundredths of a second at most. This is a Fedora 15 Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz machine. I'm not sure right now why the inline quick-sort is less of a win than on my old Fedora 14 desktop (where it was 3.24 Vs 2.01), but it's still a significant win. Perhaps others can build this simple program and tell me what they come up with. Run it here. Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz gcc version 4.6.1 (Debian 4.6.1-10) g++ -O2 qsort-inline-benchmark.c ./a.out C stdlib quick-sort time elapsed: 1.942686 seconds Inline quick-sort time elapsed: 1.126508 seconds With #define LARGE_SIZE 1 C stdlib quick-sort time elapsed: 22.158207 seconds Inline quick-sort time elapsed: 12.861018 seconds with g++ -O0 C stdlib quick-sort time elapsed: 2.736360 seconds Inline quick-sort time elapsed: 2.045619 seconds On server hardware: Intel(R) Xeon(R) CPU E5405 @ 2.00GHz gcc version 4.4.5 (Debian 4.4.5-8) /a.out C stdlib quick-sort time elapsed: 2.610150 seconds Inline quick-sort time elapsed: 1.494198 seconds All -O2 version show 42% speedup with inlined qsort. -O0 showed 25% speedup. Best regards -- Luben Karavelov
Re: [HACKERS] cheaper snapshots
- Цитат от Hannu Krosing (ha...@2ndquadrant.com), на 28.07.2011 в 22:40 - Maybe this is why other databases don't offer per backend async commit ? Isn't Oracle's COMMIT WRITE NOWAIT; basically the same - ad hoc async commit? Though their idea of backend do not maps exactly to postgrsql's idea. The closest thing is per session async commit: ALTER SESSION SET COMMIT_WRITE='NOWAIT'; Best regards -- Luben Karavelov
[HACKERS] FWD: fastlock+lazyvzid patch performance
Hello, I have seen the discussions about fastlock patch and lazy-vxid performance degradation, so I decided to test it myself. The setup: - hardware Supermicro blade 6xSAS @15k on LSI RAID: 1 disk for system + pg_xlog 4 disk RAID 10 for data 1 disk for spare 2 x Xeon E5405 @2GHz (no HT), 8 cores total 8G RAM - software Debian Sid, linux-2.6.39.1 Postgresql 9.1 beta2, compiled by debian sources incrementally applied fastlock v3 and lazy-vxid v1 patches. I have to resolve manually a conflict in src/backend/storage/lmgr/proc.c Configuration: increased shared_mem to 2G, max_connections to 500 - pgbench initiated datasert with scaling factor 100 example command invocation: ./pgbench -h 127.0.0.1 -n -S -T 30 -c 8 -j 8 -M prepared pgtest Results: clients beta2 +fastlock +lazyvzid local socket 8 76064 92430 92198 106734 16 64254 90788 90698 105097 32 56629 88189 88269 101202 64 51124 84354 8463996362 128 45455 79361 7972490625 256 40370 71904 7273782434 All runs are executed on warm cache, I made some runs for 300s with the same results (tps). I have done some runs with -M simple with identical distribution across cleints. I post this results because they somehow contradict with previous results posted on the list. In my case the patches does not only improve peak performance but also improve the performance under load - without patches the performance with 256 clients is 53% of the peak performance that is obtained with 8 clients, with patches the performance with 256 client is 79% of the peak with 8 clients. Best regards Luben Karavelov P.S. Excuse me for starting new thread - I am new on the list.
Re: [HACKERS] FWD: fastlock+lazyvzid patch performance
- Цитат от Robert Haas (robertmh...@gmail.com), на 25.06.2011 в 00:16 - On Fri, Jun 24, 2011 at 3:31 PM, wrote: clients beta2 +fastlock +lazyvzid local socket 8 76064 92430 92198 106734 16 64254 90788 90698 105097 32 56629 88189 88269 101202 64 51124 84354 84639 96362 128 45455 79361 79724 90625 256 40370 71904 72737 82434 I'm having trouble interpreting this table. Column 1: # of clients Column 2: TPS using 9.1beta2 unpatched Column 3: TPS using 9.1beta2 + fastlock patch Column 4: TPS using 9.1beta2 + fastlock patch + vxid patch Column 5: ??? 9.1beta2 + fastlock patch + vxid patch , pgbench run on unix domain socket, the other tests are using local TCP connection. At any rate, that is a big improvement on a system with only 8 cores. I would have thought you would have needed ~16 cores to get that much speedup. I wonder if the -M prepared makes a difference ... I wasn't using that option. Yes, it does make some difference, Using unpatched beta2, 8 clients with simple protocol I get 57059 tps. With all patches and simple protocol I get 60707 tps. So the difference between patched/stock is not so big. I suppose the system gets CPU bound on parsing and planning every submitted request. With -M extended I get even slower results. Luben -- Perhaps, there is no greater love than that of a revolutionary couple where each of the two lovers is ready to abandon the other at any moment if revolution demands it. Zizek
