[HACKERS] POC, WIP: OR-clause support for indexes

I'd like to present OR-clause support for indexes. Although OR-clauses could be supported by bitmapOR index scan it isn't very effective and such scan lost any order existing in index. We (with Alexander Korotkov) presented results on Vienna's conference this year. In short, it provides

Re: [HACKERS] MergeAttributes type (mod) conflict error detail

I wrote: > Amit Langote writes: >> Any specific reason why it doesn't spell out typmods in the above detail >> message? > * There's a rough policy in the parser to prefer TypeNameToString > when complaining about a TypeName input, rather than reconstructing > the

Re: [HACKERS] Add numeric_trim(numeric)

Hi 2015-11-19 3:58 GMT+01:00 Marko Tiikkaja : > Hi, > > Here's a patch for the second function suggested in > 5643125e.1030...@joh.to. This is my first patch trying to do anything > with numerics, so please be gentle. I'm sure it's full of stupid. > > January's commit fest,

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 12/23/2015 04:37 PM, Michael Paquier wrote: > On Thu, Dec 24, 2015 at 2:08 AM, Joe Conway wrote: >> On 12/23/2015 05:45 AM, Michael Paquier wrote: Yeah, the last version of the patch dates of August, and there is visibly agreement that the information of

Re: [HACKERS] Performance degradation in commit ac1d794

Andres Freund writes: > A unportable and easy version of this, actually making sense this time, > would be to use prctl(PR_SET_PDEATHSIG, SIGQUIT). That'd send SIGQUIT to > backends whenever postmaster dies. Obviously that's not portable > either - doing this for linux only

Re: [HACKERS] POC, WIP: OR-clause support for indexes

This is great. I got a question, is it possible make btree index to support OR as well? Is btree supports more invasive, in the sense that we need to do enhance ScanKey to supports an array of values? Btree now works by follow: find the max/min tuple which satisfies condtions and then

Re: [HACKERS] [POC] FETCH limited by bytes.

>Have you got numbers showing any actual performance win for postgres_fdw? For JDBC purposes, it would be nice to have an ability of asking backend "to stop fetching if produced more than X MiB of response data". For small table (4 int4 fields), having decent fetchSize (~1000) makes result

Re: [HACKERS] 9.5rc1 brin_summarize_new_values

On Sat, Dec 26, 2015 at 7:10 AM, Jeff Janes wrote: > brin_summarize_new_values() does not check that it is called on the > correct type of index, nor does it check permissions. Yeah, it should have those sanity checks... On top of that this is not a really user-friendly

Re: [HACKERS] 9.5rc1 brin_summarize_new_values

Michael Paquier writes: > On Sat, Dec 26, 2015 at 7:10 AM, Jeff Janes wrote: >> brin_summarize_new_values() does not check that it is called on the >> correct type of index, nor does it check permissions. > Yeah, it should have those sanity

Re: [HACKERS] POC, WIP: OR-clause support for indexes

Hi, Teodor, This is great. I got a question, is it possible make btree index to support OR as well? Is btree supports more invasive, in the sense that we need to do enhance ScanKey to supports an array of values? Thanks, Feng On Sat, Dec 26, 2015 at 10:04 AM, Teodor Sigaev

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Hi 2015-12-23 21:36 GMT+01:00 Daniel Verite : >Hi, > > Here's an updated patch that replaces sorted arrays by AVL binary trees > when gathering distinct values for the columns involved in the pivot. > The change is essential for large resultsets. For instance, > it

Re: [HACKERS] Performance degradation in commit ac1d794

On 2015-12-25 16:29:53 -0500, Tom Lane wrote: > Andres Freund writes: > > There's a couple solutions I can think of to that problem: > > 1) Use epoll()/kqueue, or other similar interfaces that don't require > >re-registering fds at every invocation. My guess is that that'd

Re: [HACKERS] Performance degradation in commit ac1d794

On 2015-12-26 12:22:48 +0100, Andres Freund wrote: > > > 3) Replace the postmaster_alive_fds socketpair by some other signalling > > >mechanism. E.g. sending a procsignal to each backend, which sets the > > >latch and a special flag in the latch structure. > > > > And what would send the

Re: [HACKERS] [POC] FETCH limited by bytes.

On Fri, Dec 25, 2015 at 12:31 AM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello, > > At Thu, 24 Dec 2015 18:31:42 -0500, Corey Huinker > wrote in

Re: [HACKERS] 9.5rc1 brin_summarize_new_values

Jeff Janes wrote: > On Sat, Dec 26, 2015 at 8:27 AM, Tom Lane wrote: > > Michael Paquier writes: > >> On Sat, Dec 26, 2015 at 7:10 AM, Jeff Janes wrote: > >>> brin_summarize_new_values() does not check that it is called on the

Re: [HACKERS] [POC] FETCH limited by bytes.

On Sat, Dec 26, 2015 at 6:16 AM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > >Have you got numbers showing any actual performance win for postgres_fdw? > > For JDBC purposes, it would be nice to have an ability of asking > backend "to stop fetching if produced more than X MiB of

Re: [HACKERS] 9.5rc1 brin_summarize_new_values

On Sat, Dec 26, 2015 at 8:27 AM, Tom Lane wrote: > Michael Paquier writes: >> On Sat, Dec 26, 2015 at 7:10 AM, Jeff Janes wrote: >>> brin_summarize_new_values() does not check that it is called on the >>> correct type of

[HACKERS] oldest/newestCommitTs output by pg_controldata

In looking at the exposing pg_controldata as function patch again, it struck me that the following output seems wrong: -- Latest checkpoint's oldestCommitTs: 20257 Latest checkpoint's newestCommitTs: 84159 -- Those numbers are XIDs, not timestamps. Shouldn't we either

Re: [HACKERS]WIP: Covering + unique indexes.

On Tue, Dec 1, 2015 at 4:53 AM, Anastasia Lubennikova wrote: > Finally, completed patch "covering_unique_3.0.patch" is here. > It includes the functionality discussed above in the thread, regression > tests and docs update. > I think it's quite ready for review.

Re: [HACKERS] oldest/newestCommitTs output by pg_controldata

On Sun, Dec 27, 2015 at 10:08 AM, Joe Conway wrote: > In looking at the exposing pg_controldata as function patch again, it > struck me that the following output seems wrong: > > -- > Latest checkpoint's oldestCommitTs: 20257 > Latest checkpoint's newestCommitTs:

Re: [HACKERS] 9.5rc1 brin_summarize_new_values

On Sun, Dec 27, 2015 at 1:27 AM, Tom Lane wrote: > Michael Paquier writes: >> On Sat, Dec 26, 2015 at 7:10 AM, Jeff Janes wrote: >> What do you think about the attached? > > Don't like that as-is, because dropping and

Re: [HACKERS] Add numeric_trim(numeric)

Hi 2015-12-26 21:44 GMT+01:00 Pavel Stehule : > Hi > > 2015-11-19 3:58 GMT+01:00 Marko Tiikkaja : > >> Hi, >> >> Here's a patch for the second function suggested in >> 5643125e.1030...@joh.to. This is my first patch trying to do anything >> with numerics,

Re: [HACKERS] [POC] FETCH limited by bytes.

>and fetch a number of rows that, by its estimation, would fit in the memory >available What's wrong with having size limit in the first place? It seems to make much more sense. Vladimir -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS]WIP: Covering + unique indexes.

On Sat, Dec 26, 2015 at 5:58 PM, Jeff Janes wrote: > > And the dblink contrib module fails its make check. Ignore the dblink complaint. It seems to have been some wonky build issue that is not reproducible. -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

On Fri, Dec 18, 2015 at 11:43 AM, Artur Zakirov wrote: > Hello. > > PostgreSQL has a contrib module named pg_trgm. It is used to the fuzzy text > search. It provides some functions and operators for determining the > similarity of the given texts using trigram matching.