Re: [HACKERS] getting rid of "thread fork emulation" in pgbench?

Hello Robert, I really, really wish you'd stop arguing against the patch to allow merging of pgbench logs in this basis. Hmmm. I'm lost. I thought that discussing how to best implement a feature was part of reviewing a patch. There may or may not be other reasons to reject that patch, but

Re: [HACKERS] Combining Aggregates

On Mon, Mar 30, 2015 at 2:08 PM, David Rowley wrote: > > On 18 December 2014 at 02:48, Simon Riggs wrote: > >> David, if you can update your patch with some docs to explain the >> behaviour, it looks complete enough to think about committing it in >> early January, to allow other patches that de

Re: [HACKERS] Combining Aggregates

On 18 December 2014 at 02:48, Simon Riggs wrote: > David, if you can update your patch with some docs to explain the > behaviour, it looks complete enough to think about committing it in > early January, to allow other patches that depend upon it to stand a > chance of getting into 9.5. (It is no

[HACKERS] cache lookup error for shell type creation with incompatible output function (DDL deparsing bug)

Hi all, I just bumped into the following problem in HEAD (1c41e2a): =# create type my_array_float (INPUT = array_in, OUTPUT = array_out, ELEMENT = float4, INTERNALLENGTH = 32); ERROR: XX000: cache lookup failed for type 0 LOCATION: format_type_internal, format_type.c:135 First note that in ~9.4

Re: [HACKERS] Relation extension scalability

On Mon, Mar 30, 2015 at 12:26 AM, Andres Freund wrote: > > Hello, > > Currently bigger shared_buffers settings don't combine well with > relations being extended frequently. Especially if many/most pages have > a high usagecount and/or are dirty and the system is IO constrained. > > As a quick rec

Re: [HACKERS] Relation extension scalability

Robert Haas writes: > I thought the primary reason we did this is because we wanted to > write-and-fsync the block so that, if we're out of disk space, any > attendant failure will happen before we put data into the block. Once > we've initialized the block, a subsequent failure to write or fsync

Re: [HACKERS] getting rid of "thread fork emulation" in pgbench?

On Sun, Mar 29, 2015 at 1:49 PM, Fabien COELHO wrote: > Now if we have threads, it is simpler (if the overhead is reasonable) that > threads share a file handle and just generate one file, so there is no > merging. I really, really wish you'd stop arguing against the patch to allow merging of pgb

Re: [HACKERS] Relation extension scalability

On Sun, Mar 29, 2015 at 2:56 PM, Andres Freund > As a quick recap, relation extension basically works like: > 1) We lock the relation for extension > 2) ReadBuffer*(P_NEW) is being called, to extend the relation > 3) smgrnblocks() is used to find the new target block > 4) We search for a victim bu

Re: [HACKERS] Rounding to even for numeric data type

On Mon, Mar 30, 2015 at 4:51 AM, James Cloos wrote: >> "MP" == Michael Paquier writes: > > MP> So, attached is a patch that does 1) and 2) to make clear to the > MP> user how numeric and double precision behave regarding rounding. > MP> I am adding it to CF 2015-06 to keep track of it... > >

Re: [HACKERS] Relation extension scalability

On 2015-03-29 20:02:06 -0400, Robert Haas wrote: > On Sun, Mar 29, 2015 at 2:56 PM, Andres Freund > > As a quick recap, relation extension basically works like: > > 1) We lock the relation for extension > > 2) ReadBuffer*(P_NEW) is being called, to extend the relation > > 3) smgrnblocks() is used

Re: [HACKERS] Removing INNER JOINs

David Rowley writes: > I'm not worried about the cost of the decision at plan init time. I was > just confused about what Tom was recommending. I couldn't quite decide from > his email if he meant to keep the alternative plan node around so that the > executor must transition through it for each r

Re: [HACKERS] Relation extension scalability

On 2015-03-29 16:07:49 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2015-03-29 15:21:44 -0400, Tom Lane wrote: > >> One idea that might help is to change smgrextend's API so that it doesn't > >> need a buffer to write from, but just has an API of "add a prezeroed block > >> on-disk and te

Re: [HACKERS] Relation extension scalability

Andres Freund writes: > On 2015-03-29 15:21:44 -0400, Tom Lane wrote: >> One idea that might help is to change smgrextend's API so that it doesn't >> need a buffer to write from, but just has an API of "add a prezeroed block >> on-disk and tell me the number of the block you added". On the other

Re: [HACKERS] Relation extension scalability

On 2015-03-29 15:21:44 -0400, Tom Lane wrote: > > There's two things that seem to make sense to me: > > > First, decouple relation extension from ReadBuffer*, i.e. remove P_NEW > > and introduce a bufmgr function specifically for extension. > > I think that removing P_NEW is likely to require a fai

Re: [HACKERS] Rounding to even for numeric data type

> "MP" == Michael Paquier writes: MP> So, attached is a patch that does 1) and 2) to make clear to the MP> user how numeric and double precision behave regarding rounding. MP> I am adding it to CF 2015-06 to keep track of it... Given that the examples show -2.5 rounds to -3, the IEEE term is

Re: [HACKERS] proposal: row_to_array function

2015-03-29 20:27 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > here is rebased patch. > > It contains both patches - row_to_array function and foreach array > support. > > While I don't have a problem with hstore_to_array, I don't think that > row_to_array is a very good idea; it's basically e

Re: [HACKERS] Relation extension scalability

Andres Freund writes: > As a quick recap, relation extension basically works like: > 1) We lock the relation for extension > 2) ReadBuffer*(P_NEW) is being called, to extend the relation > 3) smgrnblocks() is used to find the new target block > 4) We search for a victim buffer (via BufferAlloc())

Re: [HACKERS] compute_index_stats is missing a CHECK_FOR_INTERRUPTS

Jeff Janes writes: > On Sat, Mar 28, 2015 at 3:37 PM, Tom Lane wrote: >> Hm. The other per-sample-row loops in analyze.c use vacuum_delay_point() >> rather than CHECK_FOR_INTERRUPTS() directly. Ordinarily that wouldn't >> make much difference here, but maybe a slow index function might be >> in

[HACKERS] Relation extension scalability

Hello, Currently bigger shared_buffers settings don't combine well with relations being extended frequently. Especially if many/most pages have a high usagecount and/or are dirty and the system is IO constrained. As a quick recap, relation extension basically works like: 1) We lock the relation f

Re: [HACKERS] How about to have relnamespace and relrole?

Andrew Dunstan writes: > I have just claimed this as committer in the CF, but on reviewing the > emails it looks like there is disagreement about the need for it at all, > especially from Tom and Robert. > I confess I have often wanted regnamespace, particularly, and > occasionally regrole, si

Re: [HACKERS] getting rid of "thread fork emulation" in pgbench?

As I said, I wouldn't have a problem with restricting the --jobs setting on threadless platforms, which seems like it would fix your problem since you wouldn't need to have more than one process involved. Indeed! So I undestand that "thread fork emulation" could eventually go from your point

Re: [HACKERS] proposal: row_to_array function

Pavel Stehule writes: > here is rebased patch. > It contains both patches - row_to_array function and foreach array support. While I don't have a problem with hstore_to_array, I don't think that row_to_array is a very good idea; it's basically encouraging people to throw away SQL datatypes altoge

Re: [HACKERS] extend pgbench expressions with functions

Here is a small v2 update: v3, just a rebase. -- Fabien.diff --git a/contrib/pgbench/exprparse.y b/contrib/pgbench/exprparse.y index e68631e..049937f 100644 --- a/contrib/pgbench/exprparse.y +++ b/contrib/pgbench/exprparse.y @@ -20,6 +20,7 @@ static PgBenchExpr *make_integer_constant(int64 iv

Re: [HACKERS] improve pgbench syntax error messages

Here is a v5. Here is v6, just a rebase. -- Fabien.diff --git a/contrib/pgbench/exprparse.y b/contrib/pgbench/exprparse.y index e68631e..68c85c9 100644 --- a/contrib/pgbench/exprparse.y +++ b/contrib/pgbench/exprparse.y @@ -26,6 +26,13 @@ static PgBenchExpr *make_op(char operator, PgBenchExpr

Re: [HACKERS] getting rid of "thread fork emulation" in pgbench?

Fabien COELHO writes: >> And what will you do instead? It would be fine I think for pgbench to >> not allow --jobs different from 1 on a threadless platform, but not for >> it to fail to work altogether. > Sure. No thread really means working with only one thread. >> It looks to me like allowi

Re: [HACKERS] getting rid of "thread fork emulation" in pgbench?

Hello Tom, My question is: would someone still object strongly to the removal of this "thread fork emulation" hack in pgbench? By my count, the pthread-emulation code amounts to about 175 lines out of the nearly 4000 in pgbench.c. That's not an undue burden IMO (it's not, for comparison's sa

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

Hi I checked this patch. I like the functionality and behave. There is minor issue with outdated regress test test rules... FAILED I have no objections. Regards Pavel 2015-03-27 9:23 GMT+01:00 Haribabu Kommi : > On Fri, Mar 13, 2015 at 1:33 PM, Peter Eisentraut wrote:

Re: [HACKERS] TRAP: BadArgument - mcxt.c, Line: 813

"Erik Rijkers" writes: > I get a crash while restoring a trgm GIN index. Hm, interesting: this seems to be the first negative fallout from commit eaa5808e8ec4e82ce1a87103a6b6f687666e4e4c, which made MemoryContextReset() delete not reset child contexts. ginbuild() is creating a funcCtx as a child

Re: [HACKERS] proposal: row_to_array function

Hi here is rebased patch. It contains both patches - row_to_array function and foreach array support. This design is in conformity with hstore functions. There can be good synergy. Regards Pavel 2015-03-28 23:53 GMT+01:00 Jeff Janes : > On Tue, Jan 27, 2015 at 10:58 AM, Pavel Stehule > wrot

Re: [HACKERS] getting rid of "thread fork emulation" in pgbench?

Fabien COELHO writes: > There is a "thread fork emulation" hack which allows pgbench to be > compiled without threads by emulating them with forks, obviously with > limited capabilities. This feature is triggered by configuring postgresql > with --disable-thread-safety. > I'm not aware of plat

Re: [HACKERS] PATCH: pgbench - merging transaction logs

I also implemented a quick and dirty version for a merge log based on sharing a file handle (append mode + sprintf + fputs). I tried the "append + per-thread 2KB buffered sprintf + fputs when full", with the same number of runs. The logs are out of order by chunks, the overhead seems higher w

Re: [HACKERS] TRAP: BadArgument - mcxt.c, Line: 813

On Sun, March 29, 2015 17:40, Erik Rijkers wrote: > With the latest server > > testdb=# select version(); >version > -- > Post

[HACKERS] TRAP: BadArgument - mcxt.c, Line: 813

With the latest server testdb=# select version(); version -- PostgreSQL 9.5devel_HEAD_20150329_0154_2c33e0fbceb0 on x86_64-un

Re: [HACKERS] Rounding to even for numeric data type

On Sun, Mar 29, 2015 at 7:59 AM, Michael Paquier wrote: > On Sun, Mar 29, 2015 at 5:34 AM, Gavin Flower > wrote: >> On 28/03/15 21:58, Dean Rasheed wrote: >> [...] >>> >>> >>> Andrew mentioned that there have been complaints from people doing >>> calculations with monetary data that we don't impl

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

On Wed, Mar 25, 2015 at 2:32 PM, Michael Paquier wrote: > On Wed, Mar 25, 2015 at 8:26 AM, Tom Lane wrote: >> Hm. We're all agreed that there's a use case for exposing PG_VERSION_NUM >> to the makefiles, but I did not hear one for adding it to pg_config; and >> doing the former takes about two l

Re: [HACKERS] Rounding to even for numeric data type

On Sun, Mar 29, 2015 at 9:21 AM, Gavin Flower wrote: > On 29/03/15 13:07, David G. Johnston wrote: >> >> On Sat, Mar 28, 2015 at 3:59 PM, Michael Paquier >> mailto:michael.paqu...@gmail.com>>wrote: >> >> On Sun, Mar 29, 2015 at 5:34 AM, Gavin Flower >> >

[HACKERS] getting rid of "thread fork emulation" in pgbench?

Hello hackers, This is take 2, I already suggested this 2 years ago... There is a "thread fork emulation" hack which allows pgbench to be compiled without threads by emulating them with forks, obviously with limited capabilities. This feature is triggered by configuring postgresql with --d

Re: [HACKERS] PATCH: pgbench - merging transaction logs

Hello Tomas, The results are as follow: * 1 thread 33 runs median tps (average is consistent): - no logging:22062 - separate logging: 19360 (-12.2%) - merged logging:19326 (-12.4%, not significant from previous) Interesting. What hardware is this? Dell PowerEdge R720 wit