Re: [HACKERS] Heavily modified big table bloat even in auto vacuum is running

Amit Kapila writes: > On Sun, Jan 19, 2014 at 5:59 AM, Tom Lane wrote: >> It strikes me that there may be an obvious way to improve the number >> further, based on the observation in this thread that nkeep doesn't need >> to be scaled up because VACUUM should have scanned every page that could >>

Re: [HACKERS] array_length(anyarray)

2014/1/19 Marko Tiikkaja > On 1/19/14, 12:21 AM, Pavel Stehule wrote: > >> I checked it and I got a small issue >> >> bash-4.1$ patch -p1 < cardinality.patch >> (Stripping trailing CRs from patch.) >> >> not sure about source of this problem. >> > > I can't reproduce the problem. In fact, I don'

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On Sat, Jan 18, 2014 at 7:49 PM, Peter Geoghegan wrote: > Personally, I favor just making "case HeapTupleSelfUpdated:" within > the patch's ExecLockHeapTupleForUpdateSpec() function complain when > "hufd.cmax == estate->es_output_cid)" (currently there is a separate > complaint, but only when thos

Re: [HACKERS] improve the help message about psql -F

any commnet？ Jov blog: http:amutu.com/blog 2014/1/17 Jov > in the offical doc,-F say： > >> Use separator as the field separator for unaligned output. > > > but in the psql --help,-F say: > >> set field separator (default: "|") > > > if user don't read the offical doc ca

Re: [HACKERS] Heavily modified big table bloat even in auto vacuum is running

On Sun, Jan 19, 2014 at 5:59 AM, Tom Lane wrote: > Amit Kapila writes: >> I am marking this (based on patch vacuum_fix_v7_nkeep.patch) as Ready >> For Committer. > > I've reviewed and committed this patch, with one significant change. > If you look at the way that vacuumlazy.c computes new_rel_tu

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Sun, Jan 19, 2014 at 3:22 AM, Florian Pflug wrote: > > BTW, this made me realize that MIN and MAX currently have the same issue - > they'll rescan if the inputs are all equal. We could avoid that by doing > what > you did with dscale - track the number of times we've seen the maximum. I > wond

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On Sat, Jan 18, 2014 at 6:17 PM, Peter Geoghegan wrote: > MySQL users are not notified that this happened, and are probably > blissfully unaware that there has been a limited form of data loss. So > it's The Right Thing to say to Postgres users: "if you inserted these > rows into the table when it

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On Thu, Jan 16, 2014 at 6:31 PM, Peter Geoghegan wrote: > I think we need to give this some more thought. I have not addressed > the implications for MVCC snapshots here. So I gave this some more thought, and this is what I came up with: + static bool + ExecLockHeapTupleForUpdateSpec(EState *est

Re: [HACKERS] PoC: Partial sort

On 01/18/2014 08:13 PM, Jeremy Harris wrote: On 31/12/13 01:41, Andreas Karlsson wrote: On 12/29/2013 08:24 AM, David Rowley wrote: If it was possible to devise some way to reuse any previous tuplesortstate perhaps just inventing a reset method which clears out tuples, then we could see perform

Re: [HACKERS] GiST support for inet datatypes

Hi, I will review your two patches (gist support + selectivity). This is part 1 of my review. I will look more into the actual GiST implementation in a couple of days, but thought I could provide you with my initial input right away. inet-gist - General: I like the idea of the patc

Re: [HACKERS] Linux kernel impact on PostgreSQL performance

On Wed, Jan 15, 2014 at 5:34 AM, Jim Nasby wrote: > it's very common to create temporary file data that will never, ever, ever > actually NEED to hit disk. Where I work being able to tell the kernel to > avoid flushing those files unless the kernel thinks it's got better things > to do with that m

[HACKERS] Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements

All, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jun 12, 2013 at 3:00 PM, Peter Eisentraut wrote: > > On 6/12/13 1:29 PM, Fabrízio de Royes Mello wrote: > >> - CREATE AGGREGATE [ IF NOT EXISTS ] ... > >> - CREATE CAST [ IF NOT EXISTS ] ... > >> - CREATE COLLATION [ IF NOT EXISTS ] ...

Re: [HACKERS] Heavily modified big table bloat even in auto vacuum is running

Amit Kapila writes: > I am marking this (based on patch vacuum_fix_v7_nkeep.patch) as Ready > For Committer. I've reviewed and committed this patch, with one significant change. If you look at the way that vacuumlazy.c computes new_rel_tuples, it's based on scanned_tuples (lazy_scan_heap's num_tu

[HACKERS] [patch] Potential relcache leak in get_object_address_attribute

Hi list, It looks like the get_object_address_attribute() function has a potential relcache leak. When missing_ok=true, the relation is found but attribute is not, then the relation isn't closed, nor is it returned to the caller. I couldn't figure out any ways to trigger this, but it's best to fi

Re: [HACKERS] array_length(anyarray)

On 1/19/14, 12:21 AM, Pavel Stehule wrote: I checked it and I got a small issue bash-4.1$ patch -p1 < cardinality.patch (Stripping trailing CRs from patch.) not sure about source of this problem. I can't reproduce the problem. In fact, I don't see a single CR byte in the patch file on my di

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On Sat, Jan 18, 2014 at 5:28 AM, Robert Haas wrote: >> I was wondering if that might cause deadlocks if an existing index is >> changed from unique to non-unique, or vice versa, as the ordering would >> change. But we don't have a DDL command to change that, so the question is >> moot. > > It's no

Re: [HACKERS] array_length(anyarray)

Hello I checked it and I got a small issue bash-4.1$ patch -p1 < cardinality.patch (Stripping trailing CRs from patch.) patching file doc/src/sgml/array.sgml (Stripping trailing CRs from patch.) patching file doc/src/sgml/func.sgml (Stripping trailing CRs from patch.) patching file src/backend/ut

Re: [HACKERS] CREATE TABLESPACE WITH

On 01/18/2014 03:21 PM, Michael Paquier wrote: > So, except for the regression output problem, I think that the code is > clean so marking it as "Ready for committer" on the commit fest app. Thank you for the review. Sorry about the regression thing. I tried to randomize it a bit so that I would

Re: [HACKERS] [PATCH] Make various variables read-only (const)

Oskari Saarenmaa writes: > This allows the variables to be moved from .data to .rodata section which > means that more data can be shared by processes and makes sure that nothing > can accidentally overwrite the read-only definitions. On a x86-64 Linux > system this moves roughly 9 kilobytes of p

Re: [HACKERS] new json funcs

On 1/18/14, 9:38 PM, Andrew Dunstan wrote: On 01/18/2014 12:34 PM, Marko Tiikkaja wrote: Is it possible for you to generate a diff that doesn't have all these unrelated changes in it (from a pgindent run, I presume)? I just read through three pagefuls and I didn't see any relevant changes, but

Re: [HACKERS] new json funcs

On 01/18/2014 12:34 PM, Marko Tiikkaja wrote: On 2014-01-17 03:08, Andrew Dunstan wrote: In case anyone feels like really nitpicking, this version fixes some pgindent weirdness due to an outdated typedef list in the previous version. Is it possible for you to generate a diff that doesn't hav

Re: [HACKERS] [PATCH] Make various variables read-only (const)

I wrote: > AFAICT, this change and some similar ones are based on a false assumption. > It is *not* necessary to replace pointers by fixed-length arrays in order > to get things into .rodata. After further experimentation I find that this claim is true when compiling "normally", but apparently not

Re: [HACKERS] PoC: Partial sort

On Sat, Jan 18, 2014 at 7:22 PM, Marti Raudsepp wrote: > Total runtime: 5.418 ms Oops, shouldn't have rushed this. Clearly the timings should have tipped me off that it's broken. I didn't notice that cmpSortSkipCols was re-using tuplesort's sortkeys. Here's a patch that actually works; I added a

Re: [HACKERS] Race condition in b-tree page deletion

Heikki Linnakangas wrote: > Here's a patch implementing this scheme. This patch fixes a race condition bug in btree entry deletion.  The bug seems to rarely be encountered in practice; or at least it is generally not recognized as the cause of index corruption when that occurs. The basic approa

Re: [HACKERS] PoC: Partial sort

On 31/12/13 01:41, Andreas Karlsson wrote: On 12/29/2013 08:24 AM, David Rowley wrote: If it was possible to devise some way to reuse any previous tuplesortstate perhaps just inventing a reset method which clears out tuples, then we could see performance exceed the standard seqscan -> sort. The

Re: [HACKERS] [PATCH] Make various variables read-only (const)

Oskari Saarenmaa writes: > On Sun, Dec 22, 2013 at 09:43:57PM -0500, Robert Haas wrote: >> -#define DEF_ENC2NAME(name, codepage) { #name, PG_##name } >> +/* The extra NUL-terminator will make sure a warning is raised if the >> + * storage space for name is too small, otherwise when strlen(name) ==

Re: [HACKERS] new json funcs

On 2014-01-17 03:08, Andrew Dunstan wrote: In case anyone feels like really nitpicking, this version fixes some pgindent weirdness due to an outdated typedef list in the previous version. Is it possible for you to generate a diff that doesn't have all these unrelated changes in it (from a pgin

Re: [HACKERS] PoC: Partial sort

Funny, I just wrote a patch to do that some minutes ago (didn't see your email yet). http://www.postgresql.org/message-id/CABRT9RCK=wmFUYZdqU_+MOFW5PDevLxJmZ5B=etjjnubvya...@mail.gmail.com Regards, Marti On Sat, Jan 18, 2014 at 7:10 PM, Jeremy Harris wrote: > On 13/01/14 18:01, Alexander Kor

Re: [HACKERS] PoC: Partial sort

Hi, There's another small regression with this patch when used with expensive comparison functions, such as long text fields. If we go through all this trouble in cmpSortSkipCols to prove that the first N sortkeys are equal, it would be nice if Tuplesort could skip their comparisons entirely; tha

Re: [HACKERS] [PATCH] Make various variables read-only (const)

I wrote: > [ speculation about refactoring the API of transformRelOptions ] This morning I remembered that there's another patch in the queue with an interest in the API and behavior of transformRelOptions: https://commitfest.postgresql.org/action/patch_view?id=1318 While I think that one has no

Re: [HACKERS] PoC: Partial sort

On 13/01/14 18:01, Alexander Korotkov wrote: Thanks. It's included into attached version of patch. As wall as estimation improvements, more comments and regression tests fix. Would it be possible to totally separate the two sets of sort-keys, only giving the non-index set to the tuplesort? At

Re: [HACKERS] Changeset Extraction v7.0 (was logical changeset generation)

Robert Haas writes: > On Thu, Jan 16, 2014 at 10:15 PM, Craig Ringer wrote: >> Anybody who actually uses SHIFT_JIS as an operational encoding, rather >> than as an input/output encoding, is into pain and suffering. Personally >> I'd be quite happy to see it supported as client_encoding, but forbi

Re: [HACKERS] currawong is not a happy animal

Amit Kapila writes: > Is there any specific reason why adding PGDLLIMPORT for exporting > const variables is not good, when we are already doing for other variables > like InterruptHoldoffCount, CritSectionCount? > On searching in code, I found that for few const variables we do > extern PGDLLIMP

Re: [HACKERS] Changeset Extraction v7.0 (was logical changeset generation)

On 01/18/2014 09:31 PM, Robert Haas wrote: > On Thu, Jan 16, 2014 at 10:15 PM, Craig Ringer wrote: >> Anybody who actually uses SHIFT_JIS as an operational encoding, rather >> than as an input/output encoding, is into pain and suffering. Personally >> I'd be quite happy to see it supported as clie

Re: [HACKERS] Deprecations in authentication

On 01/16/2014 08:01 AM, Magnus Hagander wrote: On Wed, Jan 15, 2014 at 6:57 PM, Tom Lane > wrote: Magnus Hagander mailto:mag...@hagander.net>> writes: > One thing I noticed - in MSVC, the config parameter "krb5" (equivalent of > the removed --wit

[HACKERS] ALTER SYSTEM SET typos and fix for temporary file name management

Hi all, After going through commit 65d6e4c (introducing ALTER SYSTEM SET), I noticed a couple of typo mistakes as well as (I think) a weird way of using the temporary auto-configuration name postgresql.auto.conf.temp in two different places, resulting in the patch attached. It might be an overkil

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

On Jan18, 2014, at 06:15 , David Rowley wrote: >> On Sat, Jan 18, 2014 at 2:20 PM, Florian Pflug wrote: >> On Jan17, 2014, at 23:34 , David Rowley wrote: >>> The test turned out to become: >>> if (state->expectedScale == -1) >>> state->expectedScale = X.dscale; >>> else if

Re: [HACKERS] CREATE TABLESPACE WITH

On Thu, Jan 16, 2014 at 9:03 AM, Vik Fearing wrote: > New patch attached, with regression tests. Thanks for the new version, I have spent some time looking at it: - Patch compiles without warnings. - Done some manual testing with CREATE/ALTER TABLESPACE WITH and checked pg_tablespace, it worked f

Re: [HACKERS] currawong is not a happy animal

On 01/18/2014 02:42 AM, Amit Kapila wrote: On Sat, Jan 18, 2014 at 2:48 AM, Andrew Dunstan wrote: On 01/17/2014 03:15 PM, Tom Lane wrote: The other possibility I was contemplating is that "export a const variable" doesn't actually work for some reason. We're not in the habit of doing that e

Re: [HACKERS] Changeset Extraction v7.0 (was logical changeset generation)

On Thu, Jan 16, 2014 at 9:54 AM, Andres Freund wrote: >> Maybe it would be better to get rid of active/in_use and have >> three states: REPLSLOT_CONNECTED, REPLSLOT_NOT_CONNECTED, >> REPLSLOT_FREE. Or something like that. > > Hm. Color me unenthusiastic. If you feel strongly I can change it, but

Re: [HACKERS] Changeset Extraction v7.0 (was logical changeset generation)

On Thu, Jan 16, 2014 at 10:15 PM, Craig Ringer wrote: > Anybody who actually uses SHIFT_JIS as an operational encoding, rather > than as an input/output encoding, is into pain and suffering. Personally > I'd be quite happy to see it supported as client_encoding, but forbidden > as a server-side en

Re: [HACKERS] INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On Thu, Jan 16, 2014 at 3:35 AM, Heikki Linnakangas wrote: > Makes sense. Can you extract that into a separate patch, please? > > I was wondering if that might cause deadlocks if an existing index is > changed from unique to non-unique, or vice versa, as the ordering would > change. But we don't h

Re: [HACKERS] ALTER TABLESPACE ... MOVE ALL TO ...

On Thu, Jan 16, 2014 at 4:37 PM, Stephen Frost wrote: > Greetings, > > It's a day late and I'm a dollar short, but attached is a (very) minor > patch to allow users to more easily move their various objects from > one tablespace to another. Included are docs and a regression test; > I'm h