Re: [HACKERS] Docs about shared memory

Thank you, it's ideal for me :) 2015-02-27 15:21 GMT+03:00 Michael Paquier : > On Fri, Feb 27, 2015 at 9:13 PM, Vadim Gribanov > wrote: > > Hi! Where i can find explanation about how postgresql works with shared > > memory? > > Perhaps this video of Bruce's presentation about the subject would h

Re: [HACKERS] logical column ordering

On 28/02/15 18:34, Jim Nasby wrote: On 2/27/15 2:49 PM, Alvaro Herrera wrote: Tomas Vondra wrote: 1) change the order of columns in "SELECT *" - display columns so that related ones grouped together (irrespectedly whether they were added later, etc.) FWIW, I find the ordering more

Re: [HACKERS] logical column ordering

> > Even if it does fit in memory I suspect memory bandwidth is more important > than clock cycles. http://people.freebsd.org/~lstewart/articles/cpumemory.pdf This paper is old but the ratios should still be pretty accurate. Main memory is 240 clock cycles away and L1d is only 3. If the experi

Re: [HACKERS] Strange assertion using VACOPT_FREEZE in vacuum.c

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Wed, Feb 18, 2015 at 12:09 AM, Robert Haas wrote: > > I think it's right the way it is. The parser constructs a VacuumStmt > > for either a VACUUM or an ANALYZE command. That statement is checking > > that if you are doing an AN

Re: [HACKERS] logical column ordering

On 2/27/15 2:49 PM, Alvaro Herrera wrote: Tomas Vondra wrote: 1) change the order of columns in "SELECT *" - display columns so that related ones grouped together (irrespectedly whether they were added later, etc.) FWIW, I find the ordering more important for things like \d than SE

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

2015-02-28 3:12 GMT+01:00 Stephen Frost : > * Josh Berkus (j...@agliodbs.com) wrote: > > On 02/27/2015 04:41 PM, Stephen Frost wrote: > > >> we can do copy of pg_hba.conf somewhere when postmaster starts or > when it > > >> is reloaded. > > > > > > Please see my reply to Tom. There's no trivial w

Re: [HACKERS] Bug in pg_dump

On Sat, Feb 28, 2015 at 12:29 AM, Gilles Darold wrote: > Le 26/02/2015 12:41, Michael Paquier a écrit : >> On Wed, Feb 25, 2015 at 7:46 AM, Gilles Darold >> wrote: >>> This is a far better patch and the test to export/import of the >>> postgis_topology extension works great for me. >>> >>> Thank

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

2015-02-28 2:40 GMT+01:00 Tom Lane : > Stephen Frost writes: > > I understand that there may be objections to that on the basis that it's > > work that's (other than for this case) basically useless, > > Got it in one. > > I'm also not terribly happy about leaving security-relevant data sitting >

Re: [HACKERS] Proposal: knowing detail of config files via SQL

Sawada, * Sawada Masahiko (sawada.m...@gmail.com) wrote: > Attached patch is latest version including following changes. > - This view is available to super use only > - Add sourceline coulmn Alright, first off, to Josh's point- I'm definitely interested in a capability to show where the heck a g

Re: [HACKERS] logical column ordering

On 2/27/15 2:37 PM, Gavin Flower wrote: Might be an idea to allow lists of columns and their starting position. ALTER TABLE customer ALTER COLUMN (job_id, type_id, account_num) SET ORDER 3; I would certainly want something along those lines because it would be *way* less verbose (and presumab

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

2015-02-28 1:41 GMT+01:00 Stephen Frost : > Pavel, > > * Pavel Stehule (pavel.steh...@gmail.com) wrote: > > 2015-02-27 22:26 GMT+01:00 Tom Lane : > > > Stephen Frost writes: > > > > Right, we also need a view (or function, or both) which provides what > > > > the *active* configuration of the run

Re: [HACKERS] Review of GetUserId() Usage

Jeevan, * Jeevan Chalke (jeevan.cha...@gmail.com) wrote: > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: tested, passed > Documentation:tested, p

Re: [HACKERS] Improving RLS qual pushdown

Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > Attached is a patch that does that, allowing restriction clause quals > to be pushed down into subquery RTEs if they contain leaky functions, > provided that the arglists of those leaky functions contain no Vars > (such Vars would necessaril

Re: [HACKERS] Re: [COMMITTERS] pgsql: Invent a memory context reset/delete callback mechanism.

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Jeff Davis writes: > > On Fri, 2015-02-27 at 22:17 +, Tom Lane wrote: > >> In passing, per discussion, rearrange some boolean fields in struct > >> MemoryContextData so as to avoid wasted padding space. For safety, > >> this requires making allowInCrit

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

* Josh Berkus (j...@agliodbs.com) wrote: > On 02/27/2015 04:41 PM, Stephen Frost wrote: > >> we can do copy of pg_hba.conf somewhere when postmaster starts or when it > >> is reloaded. > > > > Please see my reply to Tom. There's no trivial way to reach into the > > postmaster from a backend- but

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > I understand that there may be objections to that on the basis that it's > > work that's (other than for this case) basically useless, > > Got it in one. Meh. It's hardly all that difficult and it's not useless if the user wants

Re: [HACKERS] deparsing utility commands

Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Thanks. I have adjusted the code to use ObjectAddress in all functions > called by ProcessUtilitySlow; the patch is a bit tedious but seems > pretty reasonable to me. As I said, there is quite a lot of churn. Thanks for doing this! >

Re: [HACKERS] logical column ordering

On 28/02/15 12:21, Josh Berkus wrote: On 02/27/2015 03:06 PM, Tomas Vondra wrote: On 27.2.2015 23:48, Josh Berkus wrote: Actually, I'm going to go back on what I said. We need an API for physical column reordering, even if it's just pg_ functions. The reason is that we want to enable people w

Re: [HACKERS] Re: [COMMITTERS] pgsql: Invent a memory context reset/delete callback mechanism.

Jeff Davis writes: > On Fri, 2015-02-27 at 22:17 +, Tom Lane wrote: >> In passing, per discussion, rearrange some boolean fields in struct >> MemoryContextData so as to avoid wasted padding space. For safety, >> this requires making allowInCritSection's existence unconditional; >> but I think

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

Stephen Frost writes: > I understand that there may be objections to that on the basis that it's > work that's (other than for this case) basically useless, Got it in one. I'm also not terribly happy about leaving security-relevant data sitting around in backend memory 100% of the time. We have

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

On 02/27/2015 04:41 PM, Stephen Frost wrote: >> we can do copy of pg_hba.conf somewhere when postmaster starts or when it >> is reloaded. > > Please see my reply to Tom. There's no trivial way to reach into the > postmaster from a backend- but we do get a copy of whatever the > postmaster had whe

[HACKERS] Re: [COMMITTERS] pgsql: Invent a memory context reset/delete callback mechanism.

On Fri, 2015-02-27 at 22:17 +, Tom Lane wrote: > In passing, per discussion, rearrange some boolean fields in struct > MemoryContextData so as to avoid wasted padding space. For safety, > this requires making allowInCritSection's existence unconditional; > but I think that's a better approach

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

Pavel, * Pavel Stehule (pavel.steh...@gmail.com) wrote: > 2015-02-27 22:26 GMT+01:00 Tom Lane : > > Stephen Frost writes: > > > Right, we also need a view (or function, or both) which provides what > > > the *active* configuration of the running postmaster is. This is > > > exactly what I was pr

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Right, we also need a view (or function, or both) which provides what > > the *active* configuration of the running postmaster is. This is > > exactly what I was proposing (or what I was intending to, at least) with > > pg_hba_act

Re: [HACKERS] logical column ordering

David G Johnston wrote > > Tomas Vondra-4 wrote >> But if we want to allow users to define this, I'd say let's make that >> part of CREATE TABLE, i.e. the order of columns defines logical order, >> and you use something like 'AFTER' to specify physical order. >> >> CREATE TABLE test ( >>

Re: [HACKERS] logical column ordering

On 02/27/2015 03:06 PM, Tomas Vondra wrote: > On 27.2.2015 23:48, Josh Berkus wrote: >> Actually, I'm going to go back on what I said. >> >> We need an API for physical column reordering, even if it's just pg_ >> functions. The reason is that we want to enable people writing their >> own physical

Re: [HACKERS] logical column ordering

Tomas Vondra-4 wrote > But if we want to allow users to define this, I'd say let's make that > part of CREATE TABLE, i.e. the order of columns defines logical order, > and you use something like 'AFTER' to specify physical order. > > CREATE TABLE test ( > a INT AFTER b,-- attlognum

Re: [HACKERS] logical column ordering

On 27.2.2015 23:48, Josh Berkus wrote: > On 02/27/2015 12:48 PM, Tomas Vondra wrote: >> On 27.2.2015 21:42, Josh Berkus wrote: >>> On 02/27/2015 12:25 PM, Tomas Vondra wrote: On 27.2.2015 21:09, Josh Berkus wrote: > Tomas, > > So for an API, 100% of the use cases I have for this fe

[HACKERS] Buildfarm has got the measles

A significant fraction of the buildfarm is showing this in HEAD: *** *** 375,382 create table rewritemetoo1 of rewritetype; create table rewritemetoo2 of rewritetype; alter type rewritetype alter attribute a type text cascade; - NOTICE: Table 'rewritemetoo1' is being rewrit

Re: [HACKERS] logical column ordering

On 02/27/2015 12:48 PM, Tomas Vondra wrote: > On 27.2.2015 21:42, Josh Berkus wrote: >> On 02/27/2015 12:25 PM, Tomas Vondra wrote: >>> On 27.2.2015 21:09, Josh Berkus wrote: Tomas, So for an API, 100% of the use cases I have for this feature would be satisfied by: ALT

Re: [HACKERS] MemoryContext reset/delete callbacks

Andres Freund writes: > On 2015-02-26 19:28:50 -0500, Tom Lane wrote: >> 1. I used ilists for the linked list of callback requests. This creates a >> dependency from memory contexts to lib/ilist. That's all right at the >> moment since lib/ilist does no memory allocation, but it might be >> logi

Re: [HACKERS] logical column ordering

On Feb 27, 2015 5:02 PM, "Alvaro Herrera" wrote: > > Arthur Silva wrote: > > > Sorry to intrude, I've been following this post and I was wondering if it > > would allow (in the currently planed form or in the future) a wider set of > > non-rewriting DDLs to Postgres. For example, drop a column wit

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

2015-02-27 22:26 GMT+01:00 Tom Lane : > Stephen Frost writes: > > Right, we also need a view (or function, or both) which provides what > > the *active* configuration of the running postmaster is. This is > > exactly what I was proposing (or what I was intending to, at least) with > > pg_hba_act

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

Stephen Frost writes: > Right, we also need a view (or function, or both) which provides what > the *active* configuration of the running postmaster is. This is > exactly what I was proposing (or what I was intending to, at least) with > pg_hba_active, so, again, I think we're in agreement here.

Re: [HACKERS] plpgsql versus domains

2015-02-27 21:57 GMT+01:00 Tom Lane : > Robert Haas writes: > > On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane wrote: > >> To some extent this is a workaround for the fact that plpgsql does type > >> conversions the way it does (ie, by I/O rather than by using the > parser's > >> cast mechanisms). W

Re: [HACKERS] plpgsql versus domains

Robert Haas writes: > On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane wrote: >> To some extent this is a workaround for the fact that plpgsql does type >> conversions the way it does (ie, by I/O rather than by using the parser's >> cast mechanisms). We've talked about changing that, but people seem to

Re: [HACKERS] logical column ordering

On 28/02/15 09:49, Alvaro Herrera wrote: Tomas Vondra wrote: 1) change the order of columns in "SELECT *" - display columns so that related ones grouped together (irrespectedly whether they were added later, etc.) - keep columns synced with COPY - requires user interface (A

Re: [HACKERS] POLA violation with \c service=

On Fri, Feb 27, 2015 at 02:51:18PM -0300, Alvaro Herrera wrote: > I don't understand. Why don't these patches move anything to > src/common? Because I misunderstood the scope. Hope to get to those this evening. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfe

Re: [HACKERS] logical column ordering

Tomas Vondra wrote: > 1) change the order of columns in "SELECT *" > >- display columns so that related ones grouped together > (irrespectedly whether they were added later, etc.) > >- keep columns synced with COPY > >- requires user interface (ALTER TABLE _ ALTER COLUMN _ SET

Re: [HACKERS] logical column ordering

On 27.2.2015 21:42, Josh Berkus wrote: > On 02/27/2015 12:25 PM, Tomas Vondra wrote: >> On 27.2.2015 21:09, Josh Berkus wrote: >>> Tomas, >>> >>> So for an API, 100% of the use cases I have for this feature would be >>> satisfied by: >>> >>> ALTER TABLE __ ALTER COLUMN _ SET ORDER # >>> >>>

Re: [HACKERS] logical column ordering

On 02/27/2015 12:25 PM, Tomas Vondra wrote: > On 27.2.2015 21:09, Josh Berkus wrote: >> Tomas, >> >> So for an API, 100% of the use cases I have for this feature would be >> satisfied by: >> >> ALTER TABLE __ ALTER COLUMN _ SET ORDER # >> >> and: >> >> ALTER TABLE _ ADD COLUMN colname c

Re: [HACKERS] logical column ordering

OK, so let me summarize here (the other posts in this subthread are discussing the user interface, not the use cases, so I'll respond here). There are two main use cases: 1) change the order of columns in "SELECT *" - display columns so that related ones grouped together (irrespectedly

Re: [HACKERS] logical column ordering

On 28/02/15 09:09, Josh Berkus wrote: Tomas, So for an API, 100% of the use cases I have for this feature would be satisfied by: ALTER TABLE __ ALTER COLUMN _ SET ORDER # and: ALTER TABLE _ ADD COLUMN colname coltype ORDER # If that's infeasible, a function would be less optimal,

Re: [HACKERS] logical column ordering

On 27.2.2015 21:09, Josh Berkus wrote: > Tomas, > > So for an API, 100% of the use cases I have for this feature would be > satisfied by: > > ALTER TABLE __ ALTER COLUMN _ SET ORDER # > > and: > > ALTER TABLE _ ADD COLUMN colname coltype ORDER # Yes, I imagined an interface like th

Re: [HACKERS] logical column ordering

On 27.2.2015 20:49, Alvaro Herrera wrote: > Tomas Vondra wrote: >> On 27.2.2015 20:34, Alvaro Herrera wrote: >>> Tomas Vondra wrote: >>> I think we could calls to the randomization functions into some of the regression tests (say 'create_tables.sql'), but that makes regression tests

Re: [HACKERS] logical column ordering

Tomas, So for an API, 100% of the use cases I have for this feature would be satisfied by: ALTER TABLE __ ALTER COLUMN _ SET ORDER # and: ALTER TABLE _ ADD COLUMN colname coltype ORDER # If that's infeasible, a function would be less optimal, but would work: SELECT pg_column_order

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

2015-02-27 20:55 GMT+01:00 Stephen Frost : > * Pavel Stehule (pavel.steh...@gmail.com) wrote: > > this topic should be divided, please. One part - functions for loading > > pg_hba and translating to some table. Can be two, can be one with one > > parameter. It will be used probably by advanced use

Re: [HACKERS] logical column ordering

Arthur Silva wrote: > Sorry to intrude, I've been following this post and I was wondering if it > would allow (in the currently planed form or in the future) a wider set of > non-rewriting DDLs to Postgres. For example, drop a column without > rewriting the table. Perhaps. But dropping a column

Re: [HACKERS] logical column ordering

On 2015-02-27 16:51:30 -0300, Arthur Silva wrote: > Sorry to intrude, I've been following this post and I was wondering if it > would allow (in the currently planed form or in the future) a wider set of > non-rewriting DDLs to Postgres. I don't think it makes a big difference. > For example, drop

Re: [HACKERS] remove pg_standby?

On 11/10/2014 10:54 AM, Magnus Hagander wrote: > On Mon, Nov 10, 2014 at 7:48 PM, Heikki Linnakangas > wrote: >> pg_standby is more configurable than the built-in standby_mode=on. You can >> set the sleep time, for example, while standby_mode=on uses a hard-coded >> delay of 5 s. And pg_standby ha

Re: [HACKERS] logical column ordering

* Arthur Silva (arthur...@gmail.com) wrote: > Sorry to intrude, I've been following this post and I was wondering if it > would allow (in the currently planed form or in the future) a wider set of > non-rewriting DDLs to Postgres. For example, drop a column without > rewriting the table. Uh, we al

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

* Pavel Stehule (pavel.steh...@gmail.com) wrote: > this topic should be divided, please. One part - functions for loading > pg_hba and translating to some table. Can be two, can be one with one > parameter. It will be used probably by advanced user, and I am able to > accept it like you or Tomas pr

Re: [HACKERS] logical column ordering

On Fri, Feb 27, 2015 at 4:44 PM, Tomas Vondra wrote: > On 27.2.2015 20:34, Alvaro Herrera wrote: > > Tomas Vondra wrote: > > > >> I think we could calls to the randomization functions into some of the > >> regression tests (say 'create_tables.sql'), but that makes regression > >> tests ... well,

Re: [HACKERS] logical column ordering

Tomas Vondra wrote: > On 27.2.2015 20:34, Alvaro Herrera wrote: > > Tomas Vondra wrote: > > > >> I think we could calls to the randomization functions into some of the > >> regression tests (say 'create_tables.sql'), but that makes regression > >> tests ... well, random, and I'm not convinced that

Re: [HACKERS] logical column ordering

On 27.2.2015 20:34, Alvaro Herrera wrote: > Tomas Vondra wrote: > >> I think we could calls to the randomization functions into some of the >> regression tests (say 'create_tables.sql'), but that makes regression >> tests ... well, random, and I'm not convinced that's a good thing. >> >> Also, thi

Re: [HACKERS] logical column ordering

Tomas Vondra wrote: > I think we could calls to the randomization functions into some of the > regression tests (say 'create_tables.sql'), but that makes regression > tests ... well, random, and I'm not convinced that's a good thing. > > Also, this makes regression tests harder to think, because

Re: [HACKERS] logical column ordering

On 26.2.2015 23:34, Andres Freund wrote: > On 2015-02-26 16:16:54 -0600, Jim Nasby wrote: >> On 2/26/15 4:01 PM, Alvaro Herrera wrote: >>> The reason for doing it this way is that changing the underlying >>> architecture is really hard, without having to bear an endless hackers >>> bike shed discus

Re: [HACKERS] logical column ordering

On 27.2.2015 19:50, Alvaro Herrera wrote: > Tomas Vondra wrote: >> On 26.2.2015 23:42, Kevin Grittner wrote: > >>> One use case is to be able to suppress default display of columns >>> that are used for internal purposes. For example, incremental >>> maintenance of materialized views will requir

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

2015-02-27 19:32 GMT+01:00 Stephen Frost : > * Pavel Stehule (pavel.steh...@gmail.com) wrote: > > 2015-02-27 17:59 GMT+01:00 Stephen Frost : > > > I don't think we actually care what the "current contents" are from the > > > backend's point of view- after all, when does an individual backend > eve

Re: [HACKERS] star schema and the optimizer

On 27/02/2015 19:45, Tom Lane wrote: I wrote: I had actually thought that we'd fixed this type of problem in recent versions, and that you should be able to get a plan that would look like Nestloop -> scan dim1 -> Nestloop -> scan dim2 -> indexscan fact table using dim1.

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

Attached is a diff containing the original (working) patch from my (incomplete) patch, plus regression test changes and documentation changes. While it's easy to regression-test the persistence of the fetch_size options, I am confounded as to how we would show that the fetch_size setting was respe

Re: [HACKERS] plpgsql versus domains

On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane wrote: > To some extent this is a workaround for the fact that plpgsql does type > conversions the way it does (ie, by I/O rather than by using the parser's > cast mechanisms). We've talked about changing that, but people seem to > be afraid of the compat

Re: [HACKERS] logical column ordering

Tomas Vondra wrote: > On 26.2.2015 23:42, Kevin Grittner wrote: > > One use case is to be able to suppress default display of columns > > that are used for internal purposes. For example, incremental > > maintenance of materialized views will require storing a "count(t)" > > column, and sometim

Re: [HACKERS] star schema and the optimizer

> I wrote: >> I had actually thought that we'd fixed this type of problem in recent >> versions, and that you should be able to get a plan that would look like >> Nestloop >> -> scan dim1 >> -> Nestloop >>-> scan dim2 >>-> indexscan fact table using dim1.a and dim2.b After clo

Re: [HACKERS] logical column ordering

On 26.2.2015 23:42, Kevin Grittner wrote: > Tomas Vondra wrote: > >> Over the time I've heard various use cases for this patch, but in >> most cases it was quite speculative. If you have an idea where >> this might be useful, can you explain it here, or maybe point me to >> a place where it's de

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

On 02/27/2015 10:35 AM, Stephen Frost wrote: >> From time to time I have to debug why are connection attempts failing, >> > and with moderately-sized pg_hba.conf files (e.g. on database servers >> > shared by multiple applications) that may be tricky. Identifying the >> > rule that matched (and rej

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: > On 27.2.2015 17:59, Stephen Frost wrote: > > All, > > > > * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: > >> > >> The other feature that'd be cool to have is a debugging function > >> on top of the view, i.e. a function pg_hba_check(hos

Re: [HACKERS] logical column ordering

On 27.2.2015 19:23, Alvaro Herrera wrote: > Tomas Vondra wrote: > >> Physical ordering is still determined by the CREATE TABLE command, > > In theory, you should be able to UPDATE attphysnum in pg_attribute > too when the table is empty, and new tuples inserted would follow > the specified orderi

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

* Pavel Stehule (pavel.steh...@gmail.com) wrote: > 2015-02-27 17:59 GMT+01:00 Stephen Frost : > > I don't think we actually care what the "current contents" are from the > > backend's point of view- after all, when does an individual backend ever > > use the contents of pg_hba.conf after it's up an

Re: [HACKERS] logical column ordering

Tomas Vondra wrote: > Physical ordering is still determined by the CREATE TABLE command, In theory, you should be able to UPDATE attphysnum in pg_attribute too when the table is empty, and new tuples inserted would follow the specified ordering. -- Álvaro Herrerahttp://www.2ndQu

Re: [HACKERS] logical column ordering

On 26.2.2015 23:36, Tom Lane wrote: > Jim Nasby writes: >> On 2/26/15 4:01 PM, Alvaro Herrera wrote: >>> Josh Berkus wrote: Oh, I didn't realize there weren't commands to change the LCO. Without at least SQL syntax for LCO, I don't see why we'd take it; this sounds more like a WIP

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

On Fri, Feb 27, 2015 at 12:48 PM, Tomas Vondra wrote: > On 27.2.2015 17:59, Stephen Frost wrote: > > All, > > > > * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: > >> > >> The other feature that'd be cool to have is a debugging function > >> on top of the view, i.e. a function pg_hba_check(h

Re: [HACKERS] POLA violation with \c service=

I don't understand. Why don't these patches move anything to src/common? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

On 27.2.2015 17:59, Stephen Frost wrote: > All, > > * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: >> >> The other feature that'd be cool to have is a debugging function >> on top of the view, i.e. a function pg_hba_check(host, ip, db, >> user, pwd) showing which hba rule matched. But that's

Re: [HACKERS] Bug in pg_dump

On Thu, Feb 26, 2015 at 08:41:46PM +0900, Michael Paquier wrote: > On Wed, Feb 25, 2015 at 7:46 AM, Gilles Darold > wrote: > > This is a far better patch and the test to export/import of the > > postgis_topology extension works great for me. > > > > Thanks for the work. > > Attached is a patch t

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

2015-02-27 17:59 GMT+01:00 Stephen Frost : > All, > > * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: > > On 28.1.2015 23:01, Jim Nasby wrote: > > > On 1/28/15 12:46 AM, Haribabu Kommi wrote: > > >>> >Also, what happens if someone reloads the config in the middle of > > >>> running > > >>> >t

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

All, * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote: > On 28.1.2015 23:01, Jim Nasby wrote: > > On 1/28/15 12:46 AM, Haribabu Kommi wrote: > >>> >Also, what happens if someone reloads the config in the middle of > >>> running > >>> >the SRF? > >> hba entries are reloaded only in postmaster pr

Re: [HACKERS] POLA violation with \c service=

On Mon, Feb 23, 2015 at 05:56:12PM -0300, Alvaro Herrera wrote: > > David Fetter wrote: > > > My thinking behind this was that the patch is a bug fix and intended > > to be back-patched, so I wanted to mess with as little infrastructure > > as possible. A new version of libpq seems like a very b

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

Hi, On 28.1.2015 23:01, Jim Nasby wrote: > On 1/28/15 12:46 AM, Haribabu Kommi wrote: >>> >Also, what happens if someone reloads the config in the middle of >>> running >>> >the SRF? >> hba entries are reloaded only in postmaster process, not in every >> backend. >> So there shouldn't be any probl

Re: [HACKERS] star schema and the optimizer

I wrote: > I had actually thought that we'd fixed this type of problem in recent > versions, and that you should be able to get a plan that would look like > Nestloop > -> scan dim1 > -> Nestloop > -> scan dim2 > -> indexscan fact table using dim1.a

Re: [HACKERS] star schema and the optimizer

Marc Cousin writes: > On 27/02/2015 15:08, Tom Lane wrote: >> That's right, and as you say, the planning-speed consequences of doing >> otherwise would be disastrous. > What do you mean by disastrous ? Let's assume you have ten fact tables, so ten join conditions (11 tables altogether). As-is,

Re: [HACKERS] star schema and the optimizer

On 27/02/2015 15:27, Marc Cousin wrote: > On 27/02/2015 15:08, Tom Lane wrote: >> Marc Cousin writes: >>> So I gave a look at the optimizer's code to try to understand why I got >>> this problem. If I understand correctly, the optimizer won't do cross >>> joins, except if it has no choice. >> >>

Re: [HACKERS] GSoC idea - Simulated annealing to search for query plans

Josh Berkus writes: > On 02/26/2015 05:50 PM, Fabrízio de Royes Mello wrote: >> >> On Thu, Feb 26, 2015 at 10:27 PM, Andres Freund > > wrote: >>> >>> On 2015-02-26 20:23:33 -0500, Tom Lane wrote: >>> > >>> > I seem to recall somebody demo'ing a simulated-annealing

Re: [HACKERS] Bug in pg_dump

Le 26/02/2015 12:41, Michael Paquier a écrit : > On Wed, Feb 25, 2015 at 7:46 AM, Gilles Darold > wrote: >> This is a far better patch and the test to export/import of the >> postgis_topology extension works great for me. >> >> Thanks for the work. > Attached is a patch that uses an even better a

Re: [HACKERS] star schema and the optimizer

On 27/02/2015 15:08, Tom Lane wrote: > Marc Cousin writes: >> So I gave a look at the optimizer's code to try to understand why I got this >> problem. If I understand correctly, the optimizer won't do cross joins, >> except if it has no choice. > > That's right, and as you say, the planning-spe

Re: [HACKERS] Index-only scans for GiST.

I add MemoryContext listCxt to avoid memory leak. listCxt is created once in gistrescan (only for index-only scan plan ) and reseted when scan of the leaf page is finished. I do not sure if the problem was completely solved, so I wait for feedback. * What's the reason for turning GISTScanOpaqueDa

Re: [HACKERS] star schema and the optimizer

Marc Cousin writes: > So I gave a look at the optimizer's code to try to understand why I got this > problem. If I understand correctly, the optimizer won't do cross joins, > except if it has no choice. That's right, and as you say, the planning-speed consequences of doing otherwise would be di

Re: [HACKERS] GSoC idea - Simulated annealing to search for query plans

On Thu, Feb 26, 2015 at 10:59:50PM +0100, Grzegorz Parka wrote: > Dear Hackers, > > I'm Grzegorz Parka, BSc Engineer of Technical Physics and student of > Computer Science at WUT, Poland. Last year I've been a bit into > evolutionary algorithms and during my research I found out about GEQO in > Po

Re: [HACKERS] Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> We've discussed doing $SUBJECT off and on for nearly ten years, > So, this is also changing (indirectly) the effect of ReScanExprContext > so that deletes child contexts too. Right, this is actually the main point so far as I'm concerned

Re: [HACKERS] MemoryContext reset/delete callbacks

On Thu, Feb 26, 2015 at 9:34 PM, Tom Lane wrote: > Andres Freund writes: >> It's a bit sad to push AllocSetContextData onto four cachelines from the >> current three... That stuff is hot. But I don't really see a way around >> it right now. And it seems like it'd give us more amunition to improve

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

Hi It looks well, I have only one objection. I am not sure so function "hba_settings" should be in file guc.c - it has zero relation to GUC. Maybe hba.c file is better probably. Other opinions? 2015-02-27 7:30 GMT+01:00 Haribabu Kommi : > On Sat, Feb 7, 2015 at 8:26 PM, Pavel Stehule > wrot

Re: [HACKERS] Docs about shared memory

On Fri, Feb 27, 2015 at 9:13 PM, Vadim Gribanov wrote: > Hi! Where i can find explanation about how postgresql works with shared > memory? Perhaps this video of Bruce's presentation about the subject would help: https://www.youtube.com/watch?v=Nwk-UfjlUn8 -- Michael -- Sent via pgsql-hackers

[HACKERS] Docs about shared memory

Hi! Where i can find explanation about how postgresql works with shared memory? --- Best regard Vadim Gribanov Linkedin: https://www.linkedin.com/in/yoihito Skype: v1mk550 Github: https://github.com/yoihito

Re: [HACKERS] Merge compact/non compact commits, make aborts dynamically sized

On Fri, Feb 27, 2015 at 6:49 PM, Andres Freund wrote: > On 2015-02-27 16:26:08 +0900, Michael Paquier wrote: >> On Wed, Feb 25, 2015 at 8:10 PM, Andres Freund >> wrote: >> > On 2015-02-24 20:51:42 +0200, Heikki Linnakangas wrote: >> >> On 02/20/2015 05:21 PM, Andres Freund wrote: >> >> >There's

Re: [HACKERS] How about to have relnamespace and relrole?

> The attatched are the fourth version of this patch. > > 0001-Add-regrole_v4.patch > 0002-Add-regnamespace_v4.patch > Seems like you have missed to attach both the patches. -- Jeevan B Chalke Principal Software Engineer, Product Development EnterpriseDB Corporation The Enterprise PostgreSQL Com

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 26 February 2015 at 08:39, Tomas Vondra wrote: > I've been looking at this patch, mostly because it seems like a great > starting point for improving estimation for joins on multi-column FKs. > > Currently we do this: > > CREATE TABLE parent (a INT, b INT, PRIMARY KEY (a,b)); > CREATE TAB

[HACKERS] star schema and the optimizer

Hi all, I've been facing an issue with star schemas for a while. PostgreSQL's performance is not that good without rewriting the query (or at least I couldn't find a way to make it do what I want). Here is a very basic mockup schema I used for the rest of this mail. It's of course too small to

Re: [HACKERS] Reduce pinning in btree indexes

> "Kyotaro" == Kyotaro HORIGUCHI writes: Kyotaro> Anyway I'm sorry but I have left my dev env and cannot have Kyotaro> time till next week. The point is moot; rather than try and explain it further I did the test myself, and the performance penalty of disabling mark/restore is substantial,

Re: [HACKERS] Reduce pinning in btree indexes

Hello. Mmm... We might be focusing on a bit different things.. 2015/02/27 17:27 "Andrew Gierth" > Kyotaro> I understand that you'd like to see the net drag of > Kyotaro> performance by the memcpy(), right? > > No. > > What I am suggesting is this: if mark/restore is a performance issue, > then

Re: [HACKERS] New CF app deployment

On Fri, Feb 27, 2015 at 11:32 AM, Stefan Kaltenbrunner < ste...@kaltenbrunner.cc> wrote: > On 02/26/2015 01:59 PM, Michael Paquier wrote: > > On Thu, Feb 26, 2015 at 9:15 PM, Asif Naeem wrote: > >> This thread seems relevant, Please guide me to how can access older CF > pages > >>> The MSVC porti

  1   2   >