On Wed, Feb 24, 2016 at 5:48 PM, Thomas Munro
wrote:
> Here is a first pass at that. [...]
On Wed, Feb 24, 2016 at 1:23 AM, Robert Haas wrote:
> file_fdw is parallel-safe, ...
And here is a patch to apply on top of the last one, to make file_fdw
return true. But does it really work correctly u
On Wed, Feb 24, 2016 at 7:26 AM, Tomas Vondra wrote:
> 1) I'm not quite sure why the patch adds missing_ok to fsync_fname()? The
> only place where we use missing_ok=true is in rename_safe, where right at
> the beginning we do this:
>
> fsync_fname(newfile, false, true);
>
> I.e. we're fsyncing
On Tue, Jan 12, 2016 at 6:12 PM, Andres Freund wrote:
> right now the defaults for autovacuum cost limiting are so low that they
> regularly cause problems for our users. It's not exactly obvious that
> any installation above a couple gigabytes definitely needs to change
> autovacuum_vacuum_cost_d
On Mon, Feb 22, 2016 at 4:32 AM, Tomas Vondra
wrote:
> Firstly, we could clamp the join cardinality estimate to the size of
> cartesian product, eliminating at least the most obvious over-estimates.
>
> Secondly, I think it'd be nice to somehow eliminate the sudden jumps in the
> estimates - I'm n
On Wed, Feb 24, 2016 at 9:17 AM, Tomas Vondra
wrote:
>> Well, turns out there's a quite significant difference, actually. The
>> index sizes I get (quite stable after multiple runs):
>>
>> 9.5 : 2428 MB
>> 9.6 + alone cleanup : 730 MB
>> 9.6 + pending lock : 488 MB
>>
>> So that's quit
On Wed, Feb 24, 2016 at 2:00 PM, Tatsuo Ishii wrote:
> The explanations for vacuum_freeze_table_age etc. are in the section
> "Statement Behavior", which is a subsection of "Client Connection
> Defaults". To me vacuum_freeze_table_age etc. are totally unrelated
> to "Client Connection Defaults".
>
The explanations for vacuum_freeze_table_age etc. are in the section
"Statement Behavior", which is a subsection of "Client Connection
Defaults". To me vacuum_freeze_table_age etc. are totally unrelated
to "Client Connection Defaults".
I think "Resource Consumption" section is more appropriate for
On Tue, Feb 23, 2016 at 6:45 PM, Robert Haas wrote:
> On Tue, Feb 23, 2016 at 2:06 AM, Tom Lane wrote:
>> Robert Haas writes:
Foreign tables are supposed to be categorically excluded from
parallelism. Not sure why that's not working in this instance.
>>
>> BTW, I wonder where you thin
Hi,
On 01/05/2016 10:38 AM, Tomas Vondra wrote:
Hi,
...
There shouldn't be a difference between the two approaches (although I
guess there could be if one left a larger pending list than the other,
as pending lists is very space inefficient), but since you included
9.5 in your test I thought
On Wed, Feb 24, 2016 at 01:08:29AM +, Simon Riggs wrote:
> On 23 February 2016 at 16:43, Bruce Momjian wrote:
>
> There was discussion at the FOSDEM/PGDay Developer Meeting
> (https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2016_Developer_Meeting)
> about sharding so I wanted to out
On 23 February 2016 at 22:46, Tom Lane wrote:
> Craig Ringer writes:
> > On 23 February 2016 at 21:34, Robert Haas wrote:
> >> I believe Sridhar is imagining that someday "set autocommit to false"
> >> might be a command that the server would understand.
>
> > ... I guess. Yeah.
>
> We've been
Hi,
On 02/22/2016 08:04 PM, Corey Huinker wrote:
>
> Given that counterexample, I think we not only shouldn't back-patch such a
> change but should reject it altogether.
Ouch, good point. The overflows are a different problem that we had
better address though (still on my ow
Hi,
while working of using correlation statistics when estimating GROUP BY
(or generally whatever uses estimate_num_groups), I've noticed that we
apply the selectivity in a rather naive way.
After estimating number of groups in the whole table - either by reading
pg_stats.n_distinct for a si
On 23 February 2016 at 16:43, Bruce Momjian wrote:
> There was discussion at the FOSDEM/PGDay Developer Meeting
> (https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2016_Developer_Meeting)
> about sharding so I wanted to outline where I think we are going with
> sharding and FDWs.
>
I think we need
Hi,
On 12/06/2015 11:48 PM, Tomas Vondra wrote:
/*
* Frequently, there will be no partial indexes, so first check to
* make sure there's something useful to do here.
*/
have_partial = false;
foreach(lc, rel->indexlist)
{
IndexOptInfo *index = (IndexOptInfo *) lfirst(
Hi,
On 02/08/2016 03:01 PM, Shulgin, Oleksandr wrote:
>
...
I've incorporated this fix into the v2 of my patch, I think it is
related closely enough. Also, added corresponding changes to
compute_distinct_stats(), which doesn't produce a histogram.
I think it'd be useful not to have all the c
On 2/23/16 6:04 AM, Victor Wagner wrote:
On Mon, 22 Feb 2016 17:57:36 -0600
Jim Nasby wrote:
On 2/18/16 6:26 AM, Victor Wagner wrote:
(BTW, I also disagree about using a Tcl list for prodesc. That's an
object in a *Postgres* hash table; as such it needs to be managed by
Postgres, not Tcl. AFAI
On Tue, Feb 23, 2016 at 04:09:00PM -0600, Jim Nasby wrote:
> On 2/23/16 9:37 AM, Alvaro Herrera wrote:
> >Jim Nasby wrote:
> >>On 2/5/16 10:08 AM, David Fetter wrote:
> >>>On Wed, Feb 03, 2016 at 06:02:57PM -0600, Jim Nasby wrote:
> I just discovered that ./configure will happily accept '--with
Hi,
On 02/05/2016 10:40 AM, Michael Paquier wrote:
On Thu, Feb 4, 2016 at 2:34 PM, Michael Paquier
wrote:
On Thu, Feb 4, 2016 at 12:02 PM, Michael Paquier
wrote:
On Tue, Feb 2, 2016 at 4:20 PM, Michael Paquier wrote:
...
So, attached is an updated patch that adds a new routine link_safe()
On 2/23/16 9:37 AM, Alvaro Herrera wrote:
Jim Nasby wrote:
On 2/5/16 10:08 AM, David Fetter wrote:
On Wed, Feb 03, 2016 at 06:02:57PM -0600, Jim Nasby wrote:
I just discovered that ./configure will happily accept '--with-pgport=' (I
was actually doing =$PGPORT, and didn't realize $PGPORT was e
> On 23 Feb 2016, at 11:30, Craig Ringer wrote:
>
>
> Updated patch
>
> ... attached
>
> I've split it up a bit more too, so it's easier to tell what change is for
> what and fixed the issues mentioned by Oleksii. I've also removed some
> unrelated documentation changes.
>
> Patch 0001,
2016-02-12 22:41 GMT+01:00 Jim Nasby :
> On 2/12/16 2:58 PM, Pavel Stehule wrote:
>
>>
>> So I think adding something like this needs to at least address
>> *how* SQL level access would work, *when* it's eventually implemented.
>>
>>
>> I understand - and I agree.
>>
>> small note: Private
On Thu, Aug 7, 2014 at 01:26:24PM +0900, Fujii Masao wrote:
> On Thu, Aug 7, 2014 at 2:17 AM, Bruce Momjian wrote:
> >
> > Seems we still have not addressed this.
>
> Thanks for the reminder :) I'm not sure if I have time to work on this
> for a while. If anyone is interested in this, please fee
Hello,
Here is a little patch. It fixes this issue
http://www.postgresql.org/message-id/20160217080048.26357.49...@wrigleys.postgresql.org
Without patch we get wrong result for the second email 't...@123-reg.ro':
=> SELECT * FROM ts_debug('simple', 't...@vauban-reg.ro');
alias | description
On Tue, Feb 23, 2016 at 09:54:46AM -0700, David G. Johnston wrote:
> On Tue, Feb 23, 2016 at 9:43 AM, Bruce Momjian wrote:
>
> 4. Cross-node read-write queries:
>
> This will require a global snapshot manager and global snapshot manager.
>
>
> Probably meant "global transaction manager
On Tue, Feb 23, 2016 at 9:43 AM, Bruce Momjian wrote:
> 4. Cross-node read-write queries:
>
> This will require a global snapshot manager and global snapshot manager.
>
Probably meant "global transaction manager"
David J.
There was discussion at the FOSDEM/PGDay Developer Meeting
(https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2016_Developer_Meeting)
about sharding so I wanted to outline where I think we are going with
sharding and FDWs.
First, let me point out that, unlike pg_upgrade and the Windows port,
which eit
Jim Nasby wrote:
> On 2/5/16 10:08 AM, David Fetter wrote:
> >On Wed, Feb 03, 2016 at 06:02:57PM -0600, Jim Nasby wrote:
> >>I just discovered that ./configure will happily accept '--with-pgport=' (I
> >>was actually doing =$PGPORT, and didn't realize $PGPORT was empty). What you
> >>end up with is
Fujii Masao writes:
> Attached patch implements the tab-completion for CREATE USER MAPPING command.
> Comments?
I think it's really bad style to use "Query_for_list_of_users"
as the name of a query that does not in fact deliver a list of
user names, but something else with only one specialized us
Craig Ringer writes:
> On 23 February 2016 at 21:34, Robert Haas wrote:
>> I believe Sridhar is imagining that someday "set autocommit to false"
>> might be a command that the server would understand.
> ... I guess. Yeah.
We've been there, we've done that. We're not doing it again.
Cf commits
On 23 February 2016 at 21:34, Robert Haas wrote:
> On Sat, Feb 20, 2016 at 4:14 PM, Craig Ringer
> wrote:
> >> currently PostgreSQL::"set autocommit to FALSE ( not supported )
> >
> > This also does not make any sense.
> >
> > PgJDBC does support turning autocommit off. So I don't know in what w
On Thu, Feb 18, 2016 at 11:11 AM, Amit Langote
wrote:
>> Personally, I would be more inclined to make this a CREATE TABLE statement,
>> like
>>
>> CREATE TABLE partition_name PARTITION OF parent_name FOR VALUES ...
>> CREATE TABLE subpartition_name PARTITION OF partition_name FOR VALUES ...
>
> I
On 23 February 2016 at 21:39, Craig Ringer wrote:
>
> Just finished doing that. Thanks for taking a look at the first patch so
> quickly. I hope this one's better.
>
CF entry created.
https://commitfest.postgresql.org/9/536/
--
Craig Ringer http://www.2ndQuadrant.com/
Po
On 23 February 2016 at 09:52, Michael Paquier
wrote:
> On Tue, Feb 23, 2016 at 12:29 AM, Alvaro Herrera
> wrote:
> > Craig Ringer wrote:
> >
> >> > +=pod
> >> > +
> >> > +=head2 Set up a node
> >> > pod format... Do we really want that? Considering that those modules
> >> > are only aimed at bei
On Sun, Feb 21, 2016 at 7:45 PM, Amit Kapila
wrote:
> I mean, my basic feeling is that I would not accept a 2-3% regression in
>> the single client case to get a 10% speedup in the case where we have 128
>> clients.
>>
>
> I understand your point. I think to verify whether it is run-to-run
> var
On Sat, Feb 20, 2016 at 4:14 PM, Craig Ringer wrote:
>> currently PostgreSQL::"set autocommit to FALSE ( not supported )
>
> This also does not make any sense.
>
> PgJDBC does support turning autocommit off. So I don't know in what way it's
> "not supported".
I believe Sridhar is imagining that s
On Fri, Feb 19, 2016 at 6:32 AM, Michael Paquier
wrote:
>> To be honest, my heart still balances for the Extended() interface.
>> This reduces the risk of conflicts with back-patching with 9.5.
>
> Andres, others, what else can I do to make this thread move on? I can
> produce any version of this
On Mon, Feb 22, 2016 at 7:59 PM, Tom Lane wrote:
>> No, you don't. I've spent a good deal of time thinking about that problem.
>> [ much snipped ]
>> Unless I'm missing something, though, this is a fairly obscure
>> problem. Early release of catalog locks is desirable, and locks on
>> scanned ta
Hi,
Attached patch implements the tab-completion for CREATE USER MAPPING command.
Comments?
Regards,
--
Fujii Masao
*** a/src/bin/psql/tab-complete.c
--- b/src/bin/psql/tab-complete.c
***
*** 656,661 static const SchemaQuery Query_for_list_of_matviews = {
--- 656,667
"
Rushabh pointed out that declarations of helper functions
get_useful_ecs_for_relation and get_useful_pathkeys_for_relation() are part
of FDW routines declarations rather than helper function declaration. Since
those functions are related to this patch, the attached patch moves those
declaration in
On Tue, Feb 23, 2016 at 11:47 AM, Tom Lane wrote:
> Even if there were, it would not fix this bug, because AFAICS the only
> thing that set_rel_consider_parallel is chartered to do is set the
> per-relation consider_parallel flag. The failure that is happening in
> that regression test with force
On Mon, 22 Feb 2016 17:57:36 -0600
Jim Nasby wrote:
> On 2/18/16 6:26 AM, Victor Wagner wrote:
> Are you referring to this comment?
>
> > /
> > * Add the proc description block to the
> > hashtable. Note we do
On 22 February 2016 at 23:39, Oleksii Kliukin wrote:
> What it’s doing is calling pg_basebackup first to initialize the replica,
> and that actually failed with:
>
> _basebackup: unexpected termination of replication stream: ERROR:
> requested WAL segment 0001 has already be
Hello,
At Mon, 22 Feb 2016 22:52:29 +0900, Fujii Masao wrote
in
> On Tue, Feb 16, 2016 at 4:19 PM, Masahiko Sawada
> wrote:
> > On Mon, Feb 15, 2016 at 2:54 PM, Michael Paquier
> > wrote:
> >> On Mon, Feb 15, 2016 at 2:11 PM, Kyotaro HORIGUCHI wrote:
> >>> Surprizingly yes. The list is handl
44 matches
Mail list logo