[HACKERS] any results from PL summit?

Hello is there some some result, report from PL summit? Regards Pavel Stehule -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] tab stop in README

hi, > On men, 2011-08-22 at 04:09 +, YAMAMOTO Takashi wrote: >> i know that postgresql uses ts=4 for C source code. >> but how about documatation? > > I'd say ideally don't use any tabs at all. i agree. > >> src/backend/access/transam/README seems to have both of >> ts=4 and ts=8 mixed. >

Re: [HACKERS] PATCH: regular logging of checkpoint progress

On Sat, Aug 27, 2011 at 03:57:16PM +0200, Tomas Vondra wrote: > On 27 Srpen 2011, 6:01, Noah Misch wrote: > > On Fri, Aug 26, 2011 at 10:46:33AM +0200, Tomas Vondra wrote: > >> 1. collect pg_stat_bgwriter stats > >> 2. run pgbench for 10 minutes > >> 3. collect pg_stat_bgwriter stats (to compute di

[HACKERS] strange row number estimates in pg9.1rc1

Hello hackers, I'm seeing something weird which looks like a bug in 9.1rc1 after the upgrade 8.4->9.0->9.1 done using pg_upgrade. I have a set of *static* tables for which "explain select * " gives row number estimates which are an order of magnitude lower than the actual number of rows in a

Re: [HACKERS] spinlocks on HP-UX

2011/8/28 pasman pasmański : > Pity that this patch works only on hpux :(. Well, not really. x86 is already well-behaved. On a 32-core x86 box running Linux, performs seems to plateau and level off, and then fall off gradually. But on ia64, performance just collapses after about 24 cores. The

Re: [HACKERS] spinlocks on HP-UX

Robert Haas writes: > On Sun, Aug 28, 2011 at 7:19 PM, Tom Lane wrote: >> (IOW, +1 for inventing a second macro to use in the delay loop only.) > Beautiful. Got a naming preference for that second macro? I > suggested TAS_SPIN() because it's what you use when you spin, as > opposed to what you

Re: [HACKERS] cheaper snapshots redux

On Sun, Aug 28, 2011 at 4:33 AM, Gokulakannan Somasundaram wrote: >> No, I don't think it will all be in memory - but that's part of the >> performance calculation.  If you need to check on the status of an XID >> and find that you need to read a page of data in from disk, that's >> going to be ma

Re: [HACKERS] spinlocks on HP-UX

On Sun, Aug 28, 2011 at 7:19 PM, Tom Lane wrote: > So this pretty well confirms Robert's results, in particular that all of > the win from an unlocked test comes from using it in the delay loop. > Given the lack of evidence that a general change in TAS() is beneficial, > I'm inclined to vote again

Re: [HACKERS] spinlocks on HP-UX

I wrote: > Yeah, I figured out that was probably what you meant a little while > later. I found a 64-CPU IA64 machine in Red Hat's test labs and am > currently trying to replicate your results; report to follow. OK, these results are on a 64-processor SGI IA64 machine (AFAICT, 64 independent sock

Re: [HACKERS] Why buildfarm member anchovy is failing on 8.2 and 8.3 branches

On 08/28/2011 06:21 PM, Tom Lane wrote: Andrew Dunstan writes: On 08/28/2011 05:51 PM, Tom Lane wrote: Is -O3 a recommended setting for icc? No idea. But after a bit of man-page-reading I think it's probably not the -O level that counts, so much as the fact that anchovy is using -flto (lin

Re: [HACKERS] Why buildfarm member anchovy is failing on 8.2 and 8.3 branches

Andrew Dunstan writes: > On 08/28/2011 05:51 PM, Tom Lane wrote: >>> Is -O3 a recommended setting for icc? >> No idea. But after a bit of man-page-reading I think it's probably not >> the -O level that counts, so much as the fact that anchovy is using >> -flto (link-time optimization) in CFLAGS.

Re: [HACKERS] Why buildfarm member anchovy is failing on 8.2 and 8.3 branches

On 08/28/2011 05:51 PM, Tom Lane wrote: Is -O3 a recommended setting for icc? No idea. But after a bit of man-page-reading I think it's probably not the -O level that counts, so much as the fact that anchovy is using -flto (link-time optimization) in CFLAGS. I don't see any indication that

Re: [HACKERS] spinlocks on HP-UX

Robert Haas writes: > On Sun, Aug 28, 2011 at 11:35 AM, Tom Lane wrote: >> Robert Haas writes: >>> Then, I did this: >>> >>> -       while (TAS(lock)) >>> +       while (*lock ? 1 : TAS(lock)) >> Er, what?  That sure looks like a manual application of what you'd >> already done in the TAS macr

Re: [HACKERS] spinlocks on HP-UX

On Sun, Aug 28, 2011 at 11:35 AM, Tom Lane wrote: > Robert Haas writes: >> First, I did this: > >> -#define TAS(lock) _Asm_xchg(_SZ_W, lock, 1, _LDHINT_NONE) >> +#define TAS(lock) (*(lock) ? 1 : _Asm_xchg(_SZ_W, lock, 1, _LDHINT_NONE)) > > Seems reasonable, and similar to x86 logic. > >> Then, I

Re: [HACKERS] Why buildfarm member anchovy is failing on 8.2 and 8.3 branches

Andrew Dunstan writes: > On 08/28/2011 04:15 PM, Tom Lane wrote: >> The bottom line seems to be that autoconf 2.59 is seriously broken on >> recent toolchains. Should we try to do something about that, like >> migrate the 8.2 and 8.3 releases to a newer autoconf? 8.2 is close >> enough to EOL th

Re: [HACKERS] Why buildfarm member anchovy is failing on 8.2 and 8.3 branches

On 08/28/2011 04:15 PM, Tom Lane wrote: I spent a bit of time looking into $SUBJECT. The cause of the failure is that configure mistakenly decides that setproctitle and some other functions are available, when they aren't; this eventually leads to link failures of course. Now 8.2 and 8.3 use

[HACKERS] Why buildfarm member anchovy is failing on 8.2 and 8.3 branches

I spent a bit of time looking into $SUBJECT. The cause of the failure is that configure mistakenly decides that setproctitle and some other functions are available, when they aren't; this eventually leads to link failures of course. Now 8.2 and 8.3 use autoconf 2.59. 8.4 and up, which do not exh

[HACKERS] [v9.2] Object access hooks with arguments support (v1)

The attached patch is a draft to support arguments in addition to OAT_* enum and object identifiers. The existing object_access_hook enables loadable modules to acquire control when objects are referenced. The first guest of this hook is contrib/sepgsql for assignment of default security label on

Re: [HACKERS] spinlocks on HP-UX

Robert Haas writes: > First, I did this: > -#define TAS(lock) _Asm_xchg(_SZ_W, lock, 1, _LDHINT_NONE) > +#define TAS(lock) (*(lock) ? 1 : _Asm_xchg(_SZ_W, lock, 1, _LDHINT_NONE)) Seems reasonable, and similar to x86 logic. > Then, I did this: > - while (TAS(lock)) > + while (*lock

[HACKERS] confusing invalid UTF8 byte sequence error

Has anyone else ever found this error message confusing: ERROR: 22021: invalid byte sequence for encoding "UTF8": 0xdb24 I think what is really meant is better expressed like this: ERROR: 22021: invalid byte sequence for encoding "UTF8": 0xdb 0x24 Otherwise it looks like a codepoint or a 16-b

Re: [HACKERS] Inputting relative datetimes

On 28 August 2011 00:00, Jeff MacDonald wrote: > Greetings, > > On Saturday, August 27, 2011 11:36:13 AM Dean Rasheed wrote: >> >> I'm not sure how best to handle timezones though, since it's >> hard-coded list probably won't match the timezones PostgreSQL knows >> about. Maybe that doesn't matter

Re: [HACKERS] Displaying accumulated autovacuum cost

Updated patch cleans up two diff mistakes made when backing out the progress report feature. The tip-off I screwed up should have been the absurdly high write rate shown. The usleep was accidentally deleted, so it was running without cost limits even applying. Here's a good one instead: LO

Re: [HACKERS] spinlocks on HP-UX

Pity that this patch works only on hpux :(. But i have an idea: maybe when executor stop at locked row, it should process next row instead of wait. Of course if query not contain "order by" or windowing functions. -- pasman -- Sent via pgsql-hackers mailing list (pgsql-hackers@po

Re: [HACKERS] Inputting relative datetimes

On 28 August 2011 00:39, Robert Haas wrote: > On Sat, Aug 27, 2011 at 7:43 AM, Dean Rasheed > wrote: >> On 27 August 2011 12:29, Dean Rasheed wrote: >>> ... if nothing else it has been a >>> fun exercise figuring out how the datetime string parsing code works. >> >> While looking through the cu

Re: [HACKERS] Displaying accumulated autovacuum cost

Attached patch includes "math is hard" reworking, so it displays the average write rate in the log output automatically: LOG: automatic vacuum of table "pgbench.public.pgbench_accounts": index scans: 1 pages: 0 removed, 163935 remain tuples: 200 removed, 4625165 remain buffer

Re: [HACKERS] cheaper snapshots redux

> No, I don't think it will all be in memory - but that's part of the > performance calculation. If you need to check on the status of an XID > and find that you need to read a page of data in from disk, that's > going to be many orders of magnitude slower than anything we do with s > snapshot now

[HACKERS] Call for translations

In anticipation of the release of PostgreSQL 9.1, it is once again time to update the message translations. We are now in a string freeze, which has traditionally been associated with the first release candidate, so it's a good time to do this work now. If you want to help, see