Re: [HACKERS] plpgsql_check_function - rebase for 9.3

2013-12-09 Thread Pavel Stehule
2013/12/9 Peter Eisentraut > On 12/8/13, 12:01 PM, Pavel Stehule wrote: > > But still I have no idea, how to push check without possible slowdown > > execution with code duplication > > Create a GUC parameter plpgsql.slow_checks or whatever (perhaps more > specific), which people can turn on when

Re: [HACKERS] logical changeset generation v6.7

2013-12-09 Thread Kyotaro HORIGUCHI
Hello, sorry for annoying you with meaningless questions. Your explanation made it far clearer to me. This will be the last message I mention on this patch.. On 2013-12-05 22:03:51 +0900, Kyotaro HORIGUCHI wrote: > > > - You assined HeapTupleGetOid(tuple) into relid to read in > > >several

Re: [HACKERS] plpgsql_check_function - rebase for 9.3

2013-12-09 Thread Pavel Stehule
2013/12/10 Amit Kapila > On Mon, Dec 9, 2013 at 10:54 AM, Pavel Stehule > wrote: > > 2013/12/9 Amit Kapila > >> > >> > > >> > There are two points, that should be solved > >> > > >> > a) introduction a dependency to other object in schema - now CREATE > >> > FUNCTION > >> > is fully independent

Re: [HACKERS] Get more from indices.

2013-12-09 Thread Etsuro Fujita
Kyotaro HORIGUCHI wrote: > I'm convinced of the validity of your patch. I'm satisfied with it. Thank > you. Thank you for the reply. Then, if there are no objections of others, I'll mark this as "Ready for Committer". Thanks, Best regards, Etsuro Fujita -- Sent via pgsql-hackers mailing lis

[HACKERS] Compression of tables

2013-12-09 Thread Thomas Munro
Hi I have been wondering what the minimum useful heap table compression system would be for Postgres, in order to reduce disk footprint of large mostly static datasets. Do you think an approach similar to the static row-level compression of DB2 could make sense? I imagine something like this: 1

Re: [HACKERS] Bug in VACUUM reporting of "removed %d row versions" in 9.2+

2013-12-09 Thread Simon Riggs
On 9 December 2013 21:24, Bruce Momjian wrote: > > Where are we on this? Good question, see below. >> In those commits, lazy_vacuum_heap() skipped pinned blocks, but then >> failed to report that accurately, claiming that the tuples were >> actually removed when they were not. That bug has maske

Re: [HACKERS] Optimize kernel readahead using buffer access strategy

2013-12-09 Thread KONDO Mitsumasa
Hi, I revise this patch and re-run performance test, it can work collectry in Linux and no complile wanings. I add GUC about enable_kernel_readahead option in new version. When this GUC is on(default), it works in POSIX_FADV_NORMAL which is general readahead in OS. And when it is off, it works

<    1   2