Re: [HACKERS] Testing WAL replay by comparing before and after images again

On 09/04/2015 09:30 PM, Simon Riggs wrote: On 4 September 2015 at 13:45, Heikki Linnakangas wrote: Another issue was with the new speculative insertions. Replaying a speculative insertion record sets the tuple's CTID to point to itself, like in a regular insertion. But in the

Re: [HACKERS] Double linking MemoryContext children

On 09/12/2015 11:35 AM, Kevin Grittner wrote: On the other hand, a grep indicates that there are two places that MemoryContextData.nextchild is set (and we therefore probably need to also set the new field), and Jan's proposed patch only changes one of them. If we do this, I think we need to

Re: [HACKERS] WIP: Rework access method interface

On 2015-09-14 14:34, Oleg Bartunov wrote: Whhat I don't understand from this thread if we should wait 2ndQuadrant for their sequence and column AMs or just start to work on committing it ? Alvaro, where are you ? I don't see problems with this patch from the sequence am perspective. The

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Mon, Sep 14, 2015 at 3:02 PM, Alexander Korotkov wrote: > On Sat, Sep 12, 2015 at 3:24 PM, Amit Kapila > wrote: > >> On Fri, Aug 14, 2015 at 7:23 PM, Alexander Korotkov >> wrote: >> > >> > On Thu, Aug 6, 2015 at 1:01 PM,

Re: [HACKERS] On-demand running query plans using auto_explain and signals

2015-09-14 14:11 GMT+02:00 Tomas Vondra : > > > On 09/14/2015 01:15 PM, Shulgin, Oleksandr wrote: > >> On Mon, Sep 14, 2015 at 11:53 AM, Tomas Vondra >> > >> wrote: >> >> >> On 09/14/2015 10:23

Re: [HACKERS] Scaling PostgreSQL at multicore Power8

On Monday 31 August 2015 17:43:08 Tomas Vondra wrote: > Well, I could test the patch on a x86 machine with 4 sockets (64 cores), > but I wonder whether it makes sense at this point, as the patch really > is not correct (judging by what Andres says). Can you test patch from this thread:

Re: [HACKERS] PATCH: index-only scans with partial indexes

On 09/14/2015 12:51 PM, Kyotaro HORIGUCHI wrote: I rethinked on this from the first. Sorry. Hi, this looks to be a bug of cost_index(). The attached patch would fix that. No, that's wrong. please forget the patch. The qual in qpquals should be indexquals which is excluded because it is

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Mon, Sep 14, 2015 at 5:32 AM, Alexander Korotkov wrote: > In order to build the consensus we need the roadmap for waits monitoring. > Would single byte in PgBackendStatus be the only way for tracking wait > events? Could we have pluggable infrastructure in waits

Re: [HACKERS] WIP: Rework access method interface

On Fri, Sep 11, 2015 at 4:22 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Mon, Sep 7, 2015 at 9:17 PM, Petr Jelinek wrote: > >> On 2015-09-04 16:26, Alexander Korotkov wrote: >> >>> >>> Attached patch is implementing this. It doesn't pretend to be fully

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Sun, Sep 13, 2015 at 8:06 AM, Robert Haas wrote: > > On Sat, Sep 12, 2015 at 8:24 AM, Amit Kapila wrote: > > 1. Modify the tranche mechanism so that information about LWLocks > > can be tracked easily. For this already there is some discussion,

Re: [HACKERS] PATCH: index-only scans with partial indexes

I rethinked on this from the first. > Sorry. > > > Hi, this looks to be a bug of cost_index(). The attached patch > > would fix that. > > No, that's wrong. please forget the patch. The qual in qpquals > should be indexquals which is excluded because it is not > necessary to be applied. The

Re: [HACKERS] row_security GUC, BYPASSRLS

On Mon, Sep 14, 2015 at 3:29 AM, Noah Misch wrote: > SECURITY DEFINER execution blocks SET ROLE, SET SESSION AUTHORIZATION, and > sometimes "GRANT role1 TO role2". Otherwise, it works like regular execution. > Adding exceptions, particularly silent behavior changes as opposed

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Mon, Sep 14, 2015 at 2:12 PM, Amit Kapila wrote: > On Mon, Sep 14, 2015 at 2:25 PM, Alexander Korotkov > wrote: > >> On Sat, Sep 12, 2015 at 2:05 PM, Amit Kapila >> wrote: >> >>> On Thu, Aug 6, 2015 at 3:31 PM, Ildus

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Mon, Sep 14, 2015 at 11:53 AM, Tomas Vondra wrote: > > On 09/14/2015 10:23 AM, Shulgin, Oleksandr wrote: > >> On Sat, Sep 12, 2015 at 11:50 AM, Tomas Vondra >> > >> wrote: >> > ... > >> -

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Mon, Sep 14, 2015 at 2:25 PM, Amit Kapila wrote: > On Mon, Sep 14, 2015 at 3:02 PM, Alexander Korotkov > wrote: > >> On Sat, Sep 12, 2015 at 3:24 PM, Amit Kapila >> wrote: >> >>> On Fri, Aug 14, 2015 at 7:23 PM,

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Mon, Sep 14, 2015 at 2:11 PM, Tomas Vondra wrote: > >> Now the backend that has been signaled on the second call to >> pg_cmdstatus (it can be either some other backend, or the backend B >> again) will not find an unprocessed slot, thus it will not try to >>

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Sun, Sep 13, 2015 at 5:05 PM, Ildus Kurbangaliev wrote: > Yes, that is because I tried to go with current convention working with > shmem in Postgres (there are one function that returns the size and > others that initialize that memory). But I like your

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On 09/14/2015 01:15 PM, Shulgin, Oleksandr wrote: On Mon, Sep 14, 2015 at 11:53 AM, Tomas Vondra > wrote: On 09/14/2015 10:23 AM, Shulgin, Oleksandr wrote: On Sat, Sep 12, 2015 at 11:50 AM, Tomas Vondra

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Mon, Sep 14, 2015 at 2:25 PM, Alexander Korotkov wrote: > On Sat, Sep 12, 2015 at 2:05 PM, Amit Kapila > wrote: > >> On Thu, Aug 6, 2015 at 3:31 PM, Ildus Kurbangaliev < >> i.kurbangal...@postgrespro.ru> wrote: >> > >> > On 08/05/2015 09:33 PM,

Re: [HACKERS] [COMMITTERS] pgsql: Fix an O(N^2) problem in foreign key references.

Kevin Grittner writes: > Fix an O(N^2) problem in foreign key references. Judging from the buildfarm, this patch is broken under CLOBBER_CACHE_ALWAYS. See friarbird's results in particular. I might be too quick to finger this patch, but nothing else lately has touched

[HACKERS] Re: [COMMITTERS] pgsql: Check existency of table/schema for -t/-n option (pg_dump/pg_res

On Mon, Sep 14, 2015 at 9:20 AM, Teodor Sigaev wrote: > Check existency of table/schema for -t/-n option (pg_dump/pg_restore) > > Patch provides command line option --strict-names which requires that at > least one table/schema should present for each -t/-n option. > > Pavel

Re: [HACKERS] RLS open items are vague and unactionable

Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > It shouldn't be necessary to change get_policies_for_relation() at all > to support the RETURNING check. You just need to call it with > CMD_SELECT. Yup, that works well. > BTW, your change to change get_policies_for_relation() has > a

Re: [HACKERS] On-demand running query plans using auto_explain and signals

> > Well, I didn't attach the updated patch (doing that now). > This time for real. Sorry, it's Monday :-p diff --git a/src/backend/storage/ipc/ipci.c b/src/backend/storage/ipc/ipci.c index 32ac58f..2e3beaf 100644 --- a/src/backend/storage/ipc/ipci.c +++ b/src/backend/storage/ipc/ipci.c @@ -43,6

Re: [HACKERS] Re: [COMMITTERS] pgsql: Check existency of table/schema for -t/-n option (pg_dump/pg_res

/* -* We use UNION ALL rather than UNION; this might sometimes result in -* duplicate entries in the OID list, but we don't care. +* this might sometimes result in duplicate entries in the OID list, +* but we don't care. */ This looks totally incoherent. You've

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 11 September 2015 at 15:43, Syed, Rahila wrote: > > Hello, > > Please find attached updated VACUUM progress checker patch. > Following have been accomplished in the patch > > 1. Accounts for index pages count while calculating total progress of > VACUUM. > 2. Common

[HACKERS] Attach comments to functions' parameters and return value

Hello In PostgreSQL it is possible to attach comments to almost everything. This made it possible for us to integrate the wiki that we use for our technical documentation directly with the database using the MediaWiki [1] extensions ExternalData [2] and MagicNoCache [3]. The result is a

Re: [HACKERS] Review: GiST support for UUIDs

Please post reviews to the original thread unless that's already humongously large. Otherwise somebody needs to manually link up the threads in the CF application. It also makes it much harder to follow the development because there'll likely be a new version of the patch after a review. Which

Re: [HACKERS] RLS open items are vague and unactionable

On 14 September 2015 at 14:47, Stephen Frost wrote: > Attached is a git format-patch built series which includes both commits, > now broken out, for review. > That looks OK to me. A minor point -- this comment isn't quite right: /* * For the target relation, when

[HACKERS] Review: GiST support for UUIDs

http://www.postgresql.org/message-id/flat/ca+renyvephxto1c7dfbvjp1gymuc0-3qdnwpn30-noo5mpy...@mail.gmail.com#ca+renyvephxto1c7dfbvjp1gymuc0-3qdnwpn30-noo5mpy...@mail.gmail.com Patch looks perfect but it's still needed some work. 0) rebase to current HEAD (done, in attach) 1) UUIDSIZE ->

Re: [HACKERS] RLS open items are vague and unactionable

Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > On 14 September 2015 at 14:47, Stephen Frost wrote: > > Attached is a git format-patch built series which includes both commits, > > now broken out, for review. > > That looks OK to me. Excellent. > A minor point --

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2015-09-14 13:16:46 +0300, YUriy Zhuravlev wrote: > On Friday 11 September 2015 18:50:35 you wrote: > > a) As I said upthread there's a patch to remove these locks entirely > It is very interesting. Could you provide a link?

Re: [HACKERS] Review: GiST support for UUIDs

Andres Freund wrote: Please post reviews to the original thread unless that's already humongously large. I've lost original mail. Sorry. Otherwise somebody needs to manually link up the threads in the CF application. Of course, I did it It also makes it much harder to follow the

Re: [HACKERS] Spurious standby query cancellations

On Fri, Sep 4, 2015 at 3:25 PM, Simon Riggs wrote: > On 27 August 2015 at 22:55, Jeff Janes wrote: > >> In ResolveRecoveryConflictWithLock, there is the comment: >> >> /* >> * If blowing away everybody with conflicting locks doesn't work, >>

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 2015-09-14 12:03:31 -0500, Jim Nasby wrote: > On 9/13/15 2:43 AM, David Rowley wrote: > >Are you worried about this because I've not focused on optimising float > >timestamps as much as int64 timestamps? Are there many people compiling > >with float timestamps in the real world? > > My $0.02:

Re: [HACKERS] Attach comments to functions' parameters and return value

On 9/14/15 8:59 AM, Charles Clavadetscher wrote: Hello In PostgreSQL it is possible to attach comments to almost everything. This made it possible for us to integrate the wiki that we use for our technical documentation directly with the database using the MediaWiki [1] extensions ExternalData

Re: [HACKERS] On-demand running query plans using auto_explain and signals

2015-09-14 18:46 GMT+02:00 Shulgin, Oleksandr : > On Mon, Sep 14, 2015 at 3:09 PM, Shulgin, Oleksandr < > oleksandr.shul...@zalando.de> wrote: > >> On Mon, Sep 14, 2015 at 2:11 PM, Tomas Vondra < >> tomas.von...@2ndquadrant.com> wrote: >> >>> Now the backend

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

On 9/11/15 7:45 AM, Anastasia Lubennikova wrote: This idea has obvious restriction. We can set unique only for first index columns. There is no clear way to maintain following index. CREATE INDEX index ON table (c1, c2, c3) UNIQUE ON (c1, c3); So I suggest following syntax: CREATE [UNIQUE {ON

Re: [HACKERS] Do Layered Views/Relations Preserve Sort Order ?

On 9/9/15 7:55 PM, Charles Sheridan wrote: The better question is how expensive is it to sort already sorted data. If its cheap, and it likely is, then placing explicit sorting where you care is the best solution regardless of your level of confidence that lower level sorting is being

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 9/13/15 2:43 AM, David Rowley wrote: Are you worried about this because I've not focused on optimising float timestamps as much as int64 timestamps? Are there many people compiling with float timestamps in the real world? My $0.02: the default was changed some 5 years ago so FP time is

[HACKERS] jsonb_set array append hack?

Hi, I've noticed that if you use a string for an element key in jsonb_set with create_missing set to true, you can use it to append to an array: postgres=# SELECT jsonb_set( '{"name": "Joe", "vehicle_types": ["car","van"]}'::jsonb, '{vehicle_types,nonsense}',

[HACKERS] [PATCH] add --log-output to pg_ctl on Windows

Hello The patch implements a command line option for pg_ctl on Windows to redirect logging of errors (write_stderr). The possible outputs are: default (eventlog if running as a service, otherwise stderr), stderr or eventlog. The previous discussion in BUG #13594:

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Mon, Sep 14, 2015 at 3:09 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Mon, Sep 14, 2015 at 2:11 PM, Tomas Vondra < > tomas.von...@2ndquadrant.com> wrote: > >> >>> Now the backend that has been signaled on the second call to >>> pg_cmdstatus (it can be either some other

Re: [HACKERS] Review: GiST support for UUIDs

Paul Jungwirth wrote: 2) static double uuid2num(const pg_uuid_t *i) { return *((uint64 *)i); } It isn't looked as correct transformation for me. May be, it's better to transform to numeric type (UUID looks like a 16-digit hexademical number) and follow

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

On 9/14/15 1:50 PM, Thomas Munro wrote: CREATE [UNIQUE {ON FIRST {COLUMN | n_unique_column COLUMNS}} INDEX ON table_name (column_name1, column_name2 ...); I would use the first (simple) syntax and just throw an error if the user tries to skip

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

On 14 September 2015 at 22:44, Jim Nasby wrote: > On 9/14/15 1:50 PM, Thomas Munro wrote: > >> CREATE [UNIQUE {ON FIRST {COLUMN | n_unique_column COLUMNS}} >> INDEX ON >> table_name (column_name1, column_name2 ...); >> >> >> I

Re: [HACKERS] Re: [COMMITTERS] pgsql: Check existency of table/schema for -t/-n option (pg_dump/pg_res

On Mon, Sep 14, 2015 at 10:54 AM, Teodor Sigaev wrote: >> /* >> -* We use UNION ALL rather than UNION; this might sometimes result in >> -* duplicate entries in the OID list, but we don't care. >> +* this might sometimes result in duplicate entries in the OID

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 9/8/15 4:56 PM, Andrew Dunstan wrote: > The problem is that at least this user's system had something odd about > it. so that I wouldn't entirely trust the output of > >select is_supported >from information_schema.sql_features >where feature_name = 'XML type'; > > to reflect the

Re: [HACKERS] Can extension build own SGML document?

Peter Eisentraut wrote: > On 9/14/15 5:35 AM, Kouhei Kaigai wrote: > > Hello, > > > > The pgxs makefile (pgxs.ml) says: > > > > # DOCS -- random files to install under $PREFIX/doc/$MODULEDIR > > > > It is a bunch of files to be copied to document directory, however, > > not looks like a

Re: [HACKERS] Can extension build own SGML document?

On Tue, Sep 15, 2015 at 6:01 AM, Alvaro Herrera wrote: > I think the only way upstream Postgres could offer this is as a way to > build a separate "book", i.e. not a chapter/section within the main > book. I think it would require huge complications in doc/src/sgml's > Makefile. Not sure it's

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

On Tue, Sep 15, 2015 at 12:44 AM, Jim Nasby wrote: > On 9/14/15 1:50 PM, Thomas Munro wrote: > >> CREATE [UNIQUE {ON FIRST {COLUMN | n_unique_column COLUMNS}} >> INDEX ON >> table_name (column_name1, column_name2 ...); >> >> >>

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

On 14 September 2015 at 23:12, Oleg Bartunov wrote: > > > > On Tue, Sep 15, 2015 at 12:44 AM, Jim Nasby > wrote: > >> On 9/14/15 1:50 PM, Thomas Munro wrote: >> >>> CREATE [UNIQUE {ON FIRST {COLUMN | n_unique_column COLUMNS}} >>>

Re: [HACKERS] [PATCH] add --log-output to pg_ctl on Windows

On Mon, Sep 14, 2015 at 7:42 PM, Egon Kocjan wrote: > Hello > > The patch implements a command line option for pg_ctl on Windows to redirect > logging of errors (write_stderr). The possible outputs are: default > (eventlog if running as a service, otherwise stderr), stderr or

Re: [HACKERS] Review: GiST support for UUIDs

Or something like this in pseudocode: numeric = int8_numeric(*(uint64 *)(>data[0])) * int8_numeric(MAX_INT64) + int8_numeric(*(uint64 *)(>data[8])) This is more like what I was hoping for, rather than converting to a string and back. Would you mind confirming for me: int8_numeric turns an

Re: [HACKERS] cache type info in json_agg and friends

On 09/14/2015 03:42 PM, Teodor Sigaev wrote: Currently, json_agg, jsonb_agg, json_object_agg and jsonb_object_agg do type classification on their arguments on each call to the transition function. This is quite unnecessary, as the argument types won't change. This patch remedies the defect by

Re: [HACKERS] Can extension build own SGML document?

On 9/14/15 5:35 AM, Kouhei Kaigai wrote: > Hello, > > The pgxs makefile (pgxs.ml) says: > > # DOCS -- random files to install under $PREFIX/doc/$MODULEDIR > > It is a bunch of files to be copied to document directory, however, > not looks like a variable to specify SGML source as PostgreSQL

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 15 September 2015 at 05:52, Alvaro Herrera wrote: > Jim Nasby wrote: > > On 9/13/15 2:43 AM, David Rowley wrote: > > >Are you worried about this because I've not focused on optimising float > > >timestamps as much as int64 timestamps? Are there many people compiling

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

On 15/09/15 09:44, Jim Nasby wrote: On 9/14/15 1:50 PM, Thomas Munro wrote: CREATE [UNIQUE {ON FIRST {COLUMN | n_unique_column COLUMNS}} INDEX ON table_name (column_name1, column_name2 ...); I would use the first (simple) syntax and just throw an

Re: [HACKERS] row_security GUC, BYPASSRLS

On Mon, Sep 14, 2015 at 07:30:33AM -0400, Robert Haas wrote: > On Mon, Sep 14, 2015 at 3:29 AM, Noah Misch wrote: > > Pondering it afresh this week, I see now that row_security=force itself is > > the > > problem. It's a new instance of the maligned "behavior-changing GUC". >

Re: [HACKERS] row_security GUC, BYPASSRLS

Noah Misch writes: > On Mon, Sep 14, 2015 at 07:30:33AM -0400, Robert Haas wrote: >> ...but I'm not sure I like this, either. Without row_security=force, >> it's hard for a table owner to test their policy, unless they have the >> ability to assume some other user ID, which

Re: [HACKERS] Attach comments to functions' parameters and return value

Hello Àlvaro On 14/09/2015 20:02, Alvaro Herrera wrote: Jim Nasby wrote: On 9/14/15 8:59 AM, Charles Clavadetscher wrote: To long time PostgreSQL developers this may look straightforward. For the moment I am not even sure if that is correct and if there are other places that would need

Re: [HACKERS] Attach comments to functions' parameters and return value

Hello Jim On 14/09/2015 19:23, Jim Nasby wrote: On 9/14/15 8:59 AM, Charles Clavadetscher wrote: Hello In PostgreSQL it is possible to attach comments to almost everything. This made it possible for us to integrate the wiki that we use for our technical documentation directly with the

Re: [HACKERS] Parallel Seq Scan

On Thu, Sep 10, 2015 at 2:12 PM, Amit Kapila wrote: > On Thu, Sep 10, 2015 at 4:16 AM, Robert Haas wrote: >> >> On Wed, Sep 9, 2015 at 11:07 AM, Amit Kapila >> wrote: >> > On Wed, Sep 9, 2015 at 11:47 AM, Haribabu Kommi >>

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Sep 11, 2015 at 6:41 AM, Beena Emerson wrote: > Hello, > > Please find attached the WIP patch for the proposed feature. It is built > based on the already discussed design. > > Changes made: > - add new parameter "sync_file" to provide the location of the

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2015-09-14 17:41:42 +0200, Andres Freund wrote: > I pointed out how you can actually make this safely lock-free giving you > the interesting code. And here's an actual implementation of that approach. It's definitely work-in-progress and could easily be optimized further. Don't have any big

Re: [HACKERS] WIP: Make timestamptz_out less slow.

David Rowley wrote: > It's not like nothing is improved in float timestamps with this patch, it's > only appending the non-zero fractional seconds that I've left alone. Every > other portion of the timestamp has been improved. OK, sounds good enough to me. > I did, however spend some time a few

Re: [HACKERS] Mention column name in error messages

On Wed, Aug 19, 2015 at 11:31 PM, Jeff Janes wrote: > > I took this for a test drive, and had some comments.on the user visible > parts. > [...] > But I think these belong as CONTEXT or as DETAIL, not as HINT. The > messages are giving me details about where (which column)

Re: [HACKERS] Mention column name in error messages

Franck Verrot wrote: > On Wed, Aug 19, 2015 at 11:31 PM, Jeff Janes wrote: > > > > I took this for a test drive, and had some comments.on the user visible > > parts. > > [...] > > But I think these belong as CONTEXT or as DETAIL, not as HINT. The > > messages are giving me

Re: [HACKERS] Multi-tenancy with RLS

On Fri, Sep 11, 2015 at 7:50 AM, Joe Conway wrote: > On 09/01/2015 11:25 PM, Haribabu Kommi wrote: >> If any user is granted any permissions on that object then that user >> can view it's meta data of that object from the catalog tables. >> To check the permissions of the user

[HACKERS] row_security GUC, BYPASSRLS

On Thu, Sep 10, 2015 at 03:23:13PM -0400, Stephen Frost wrote: > First off, thanks again for your review and comments on RLS. Hopefully > this addresses the last remaining open item from that review. Item (3a), too, remains open. > * Noah Misch (n...@leadboat.com) wrote: > > On Wed, Feb 25,

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

> 12 сент. 2015 г., в 14:05, Amit Kapila написал(а): > > On Thu, Aug 6, 2015 at 3:31 PM, Ildus Kurbangaliev > > wrote: > > > > On 08/05/2015 09:33 PM, Robert Haas wrote: > >> > >> > >> You're missing

Re: [HACKERS] PATCH: index-only scans with partial indexes

Hi, At Sun, 13 Sep 2015 23:21:30 +0200, Tomas Vondra wrote in <55f5e8da.8080...@2ndquadrant.com> > That's indeed strange, but after poking into that for a while, it > seems rather like a costing issue. Let me demonstrate: ... > Now, both plans are index only scans,

Re: [HACKERS] Parser emits mysterious error message for very long tokens

Hello, thank you for the opinion. At Fri, 11 Sep 2015 09:31:30 -0400, Tom Lane wrote in <884.1441978...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > Hello, this is a problem on an extreme situation. > > When parser encounters very long

Re: [HACKERS] PATCH: index-only scans with partial indexes

On 09/14/2015 09:35 AM, Kyotaro HORIGUCHI wrote: Hi, ,,, Which is exactly the difference between costs from amcostestimate idx1: 4769.115000 + 0.015 * 297823 = 9236.46 idx2: 6258.23 + 0.010 * 297823 = 9236.46 These calculations are exactly right, but you overlooked the

Re: [HACKERS] WIP: Make timestamptz_out less slow.

Jim Nasby wrote: > On 9/13/15 2:43 AM, David Rowley wrote: > >Are you worried about this because I've not focused on optimising float > >timestamps as much as int64 timestamps? Are there many people compiling > >with float timestamps in the real world? > > My $0.02: the default was changed some

Re: [HACKERS] Attach comments to functions' parameters and return value

Jim Nasby wrote: > On 9/14/15 8:59 AM, Charles Clavadetscher wrote: > >To long time PostgreSQL developers this may look straightforward. For the > >moment I am not even sure if that is correct and if there are other places > >that would need additions, apart from the obvious display in psql. > >

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

CREATE INDEX index ON table (c1, c2, c3) UNIQUE ON (c1, c3); CREATE [UNIQUE {ON FIRST {COLUMN | n_unique_column COLUMNS}} INDEX ON table_name (column_name1, column_name2 ...); I would use the first (simple) syntax and just throw an error if the user tries to skip a column on the UNIQUE clause.

Re: [HACKERS] cache type info in json_agg and friends

Currently, json_agg, jsonb_agg, json_object_agg and jsonb_object_agg do type classification on their arguments on each call to the transition function. This is quite unnecessary, as the argument types won't change. This patch remedies the defect by caching the necessary values in the aggregate

Re: [HACKERS] cache type info in json_agg and friends

Andrew Dunstan wrote: > Currently, json_agg, jsonb_agg, json_object_agg and jsonb_object_agg do type > classification on their arguments on each call to the transition function. > This is quite unnecessary, as the argument types won't change. This patch > remedies the defect by caching the

Re: [HACKERS] Review: GiST support for UUIDs

2) static double uuid2num(const pg_uuid_t *i) { return *((uint64 *)i); } It isn't looked as correct transformation for me. May be, it's better to transform to numeric type (UUID looks like a 16-digit hexademical number) and follow gbt_numeric_penalty()

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

On Tue, Sep 15, 2015 at 6:08 AM, Teodor Sigaev wrote: > CREATE INDEX index ON table (c1, c2, c3) UNIQUE ON (c1, c3); >>> >>> CREATE [UNIQUE {ON FIRST {COLUMN | n_unique_column COLUMNS}} INDEX ON >>> table_name (column_name1, column_name2 ...); >>> >> >> I would use the first

Re: [HACKERS] jsonb_set array append hack?

On 09/14/2015 01:29 PM, Thom Brown wrote: Hi, I've noticed that if you use a string for an element key in jsonb_set with create_missing set to true, you can use it to append to an array: postgres=# SELECT jsonb_set( '{"name": "Joe", "vehicle_types": ["car","van"]}'::jsonb,

[HACKERS] cache type info in json_agg and friends

Currently, json_agg, jsonb_agg, json_object_agg and jsonb_object_agg do type classification on their arguments on each call to the transition function. This is quite unnecessary, as the argument types won't change. This patch remedies the defect by caching the necessary values in the

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Sat, Sep 12, 2015 at 11:50 AM, Tomas Vondra wrote: > Hi, > > I did a quick initial review of this patch today, so here are my comments > so far: > Hi Tomas, First of all, thanks for the review! - ipcs.c should include utils/cmdstatus.h (the compiler complains

Re: [HACKERS] extend pgbench expressions with functions

Hi, I had a look on this, this gives amazing performance. (I myself haven't tried that yet:-p) But anyway the new syntax looks far smarter than preparing arbitraly metacommands. michael> I have moved this patch to the next CF. > > Hello Heikki, > > > >>> As soon as we add more functions, the way

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Sat, Sep 12, 2015 at 2:05 PM, Amit Kapila wrote: > On Thu, Aug 6, 2015 at 3:31 PM, Ildus Kurbangaliev < > i.kurbangal...@postgrespro.ru> wrote: > > > > On 08/05/2015 09:33 PM, Robert Haas wrote: > >> > >> > >> You're missing the point. Those multi-byte fields have

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Sat, Sep 12, 2015 at 3:24 PM, Amit Kapila wrote: > On Fri, Aug 14, 2015 at 7:23 PM, Alexander Korotkov > wrote: > > > > On Thu, Aug 6, 2015 at 1:01 PM, Ildus Kurbangaliev < > i.kurbangal...@postgrespro.ru> wrote: > >> > >> > >> I've looked

[HACKERS] Can extension build own SGML document?

Hello, The pgxs makefile (pgxs.ml) says: # DOCS -- random files to install under $PREFIX/doc/$MODULEDIR It is a bunch of files to be copied to document directory, however, not looks like a variable to specify SGML source as PostgreSQL core doing. Do we have way to build SGML source of

Re: [HACKERS] Partitioned checkpointing

Hi, I wrote: > The original purpose is to mitigate full-page-write rush that occurs at > immediately after the beginning of each checkpoint. > The amount of FPW at each checkpoint is reduced to 1/16 by the > 'Partitioned checkpointing.' Let me show another set of measurement results that clearly

Re: [HACKERS] RLS open items are vague and unactionable

On 13 September 2015 at 22:54, Stephen Frost wrote: > Not in front of my laptop and will review it when I get back in more detail, > but the original approach that I tried was changing > get_policies_for_relation to try and build everything necessary, which > didn't work as we

Re: [HACKERS] On-demand running query plans using auto_explain and signals

2015-09-14 10:23 GMT+02:00 Shulgin, Oleksandr : > > > > I can think of something like: > > EXPLAIN [ ( option [, ...] ) ] PROCESS ; > > where option is extended with: > > QUERY > PROGRESS > BACKTRACE > > in addition to the usual ANALYZE, VERBOSE, FORMAT, etc.

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On 09/14/2015 10:23 AM, Shulgin, Oleksandr wrote: On Sat, Sep 12, 2015 at 11:50 AM, Tomas Vondra > wrote: ... - Attempts to get plan for simple insert queries like this INSERT INTO x SELECT * FROM x;

[HACKERS] Re: Review: check existency of table for -t option (pg_dump) when pattern...

(new version in attach), but patch shows some inconsistent output: % pg_dump -t 'aaa*' postgres pg_dump: No matching tables were found % pg_dump -t 'aaa*' --strict-names postgres pg_dump: Table "aaa*" not found. There are two different situation - first message says "there

Re: [HACKERS] Review: check existency of table for -t option (pg_dump) when pattern...

2015-09-14 12:05 GMT+02:00 Teodor Sigaev : > (new version in attach), but patch shows some inconsistent output: >> % pg_dump -t 'aaa*' postgres >> pg_dump: No matching tables were found >> % pg_dump -t 'aaa*' --strict-names postgres >> pg_dump: Table "aaa*"

Re: [HACKERS] PATCH: index-only scans with partial indexes

Hi, this looks to be a bug of cost_index(). The attached patch would fix that. = The following part in cost_index, > cpu_per_tuple = cpu_tuple_cost + qpqual_cost.per_tuple; > > run_cost += cpu_per_tuple * tuples_fetched; Adds, *cpu_tuple_cost* (which is 0.01) + qpqual_cost.per_tuple

Re: [HACKERS] PATCH: index-only scans with partial indexes

Sorry. > Hi, this looks to be a bug of cost_index(). The attached patch > would fix that. No, that's wrong. please forget the patch. The qual in qpquals should be indexquals which is excluded because it is not necessary to be applied. The right way would be remove the cost for qpqual in

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Friday 11 September 2015 18:50:35 you wrote: > a) As I said upthread there's a patch to remove these locks entirely It is very interesting. Could you provide a link? And it's not very good, since there is a bottleneck PinBuffer / UnpinBuffer instead of LWLocks. > b) It doesn't matter anyway.