Bruce Momjian wrote:
>> !distinct column values, a generic plan assumes a column equality
>> !comparison will match 33% of processed rows. Column statistics
>>
>> ... assumes *that* a column equality comparison will match 33% of *the*
>> processed rows.
>
> Uh, that seems overly wordy.
On Sun, Jun 5, 2016 at 11:01 PM, Andreas Seltenreich wrote:
> Creating some foreign tables via postgres_fdw in the regression db of
> master as of de33af8, sqlsmith triggers the following assertion:
>
> TRAP: FailedAssertion("!(const Node*)(var))->type) == T_Var))", File:
> "deparse.c", L
On 2016/06/05 23:01, Andreas Seltenreich wrote:
> Creating some foreign tables via postgres_fdw in the regression db of
> master as of de33af8, sqlsmith triggers the following assertion:
>
> TRAP: FailedAssertion("!(const Node*)(var))->type) == T_Var))", File:
> "deparse.c", Line: 1116)
>
On 2016/06/07 14:41, Michael Paquier wrote:
> On Fri, Apr 22, 2016 at 1:25 AM, David G. Johnston
> wrote:
>> On Wed, Apr 20, 2016 at 9:18 PM, Amit Langote
>> wrote:
>>> I agree it's unclear. Does the following make it any better (updated
>>> patch attached):
>
> I have sent a patch to rework th
On Fri, Jun 03, 2016 at 12:31:44PM -0400, Stephen Frost wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
> > On Fri, Jun 3, 2016 at 8:57 PM, Thom Brown wrote:
> > > If a database with the bloom extension installed is dumped and restored,
> > > there's an error with the access method c
On Tue, Jun 7, 2016 at 6:55 AM, Michael Paquier
wrote:
> On Tue, Jun 7, 2016 at 12:01 AM, Robert Haas wrote:
>> On Fri, Jun 3, 2016 at 12:31 PM, Stephen Frost wrote:
Stephen, something is smelling wrong in checkExtensionMembership()
since 5d58999, an access method does not have ACLs an
On Fri, Apr 22, 2016 at 1:25 AM, David G. Johnston
wrote:
> On Wed, Apr 20, 2016 at 9:18 PM, Amit Langote
> wrote:
>> I agree it's unclear. Does the following make it any better (updated
>> patch attached):
I have sent a patch to rework the docs here:
http://www.postgresql.org/message-id/cab7np
On Fri, Jun 3, 2016 at 11:25 PM, Tom Lane wrote:
> Michael Paquier writes:
>> Actually, the docs could be more polished.
>
> I think the docs could stand to be rewritten from scratch ;-). But
> upthread there was an offer to work on them if we made the code behavior
> saner. I've done the latte
Thanks for this patch. I have reviewed it:
On Sun, May 15, 2016 at 12:53:13PM +, Clément Prévost wrote:
> After some experiments, I found out that, for my setup (9b7bfc3a88ef7b), a
> parallel seq scan is used given both parallel_setup_cost
> and parallel_tuple_cost are set to 0 and given that
On Sat, Jun 4, 2016 at 1:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> Yeah, but what if somebody doesn't want to store scopes?
>
> [ shrug... ] We can invent a "strip_scope()" sort of function,
> analogous to the weight-stripping function for tsvectors, or several
> other examples. That's a
On Tue, Jun 7, 2016 at 7:35 AM, Alvaro Herrera wrote:
> In looking at the DROP ACCESS METHOD completion I noticed that the
> words_after_create gadget is a bit buggy: for things with more than one
> word in the thing name (such as MATERIALIZED VIEW, USER MAPPING FOR,
> EVENT TRIGGER among others)
On Tue, Jun 7, 2016 at 12:31 PM, Michael Paquier
wrote:
> On Tue, Jun 7, 2016 at 12:28 AM, Alvaro Herrera
> wrote:
>> Tom Lane wrote:
>>> Alvaro Herrera writes:
>>
>>> > I can't imagine that the server is avoiding hash aggregation on a 1MB
>>> > work_mem limit for data that's a few dozen of byte
Existing application code written to call function in Oracle which return
no.of rows in out parameter and return-values is cursor-result
this need migrate to PostgreSQL, need help here
example: (actual function declaration only)
*Oracle:*
CREATE OR REPLACE PROCEDURE sc_getapppermissionlist (
On Tue, Jun 7, 2016 at 12:28 AM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> Alvaro Herrera writes:
>
>> > I can't imagine that the server is avoiding hash aggregation on a 1MB
>> > work_mem limit for data that's a few dozen of bytes. Is it really doing
>> > that?
>>
>> Yup:
>
> Aha. Thanks for
At Mon, 06 Jun 2016 11:12:14 -0400, Tom Lane wrote in
<17504.1465225...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > At Fri, 03 Jun 2016 09:44:30 -0400, Tom Lane wrote in
> > <11515.1464961...@sss.pgh.pa.us>
> >> I think that this one:
> >>> If the target thread is allocating memory from the
There appears to be a problem with how client encoding is handled in the
communication from parallel workers. In a parallel worker, the client
encoding setting is inherited from its creating process as part of the
GUC setup. So any plain-text stuff the parallel worker sends to its
leader is a
Thanks for the review, Fabrízio.
Attached is the updated patch, rebased and tested against master.
I integrated feedback from your first point and am no longer
HS_POLLUTE'ing the namespace for the new function.
With regards to your second point- I've been maintaining consistency
with the rest of
Michael Paquier wrote:
> On Thu, Jun 2, 2016 at 3:42 PM, Michael Paquier
> wrote:
> > On Thu, Jun 2, 2016 at 1:00 PM, Michael Paquier
> > wrote:
> >> I have added an open item for 9.6 regarding this patch, that would be
> >> good to complete this work in this release for consistency with the
> >>
On Tue, Jun 7, 2016 at 12:01 AM, Robert Haas wrote:
> On Fri, Jun 3, 2016 at 12:31 PM, Stephen Frost wrote:
>>> Stephen, something is smelling wrong in checkExtensionMembership()
>>> since 5d58999, an access method does not have ACLs and I would have
>>> expected that when this routine is invoked
Hi,
On 2016-06-06 17:22:38 -0400, Robert Haas wrote:
> > I'd also be ok with adding & documenting (beta release notes)
> > CREATE EXTENSION pg_visibility;
> > SELECT relname FROM pg_class WHERE relkind IN ('r', 'm') AND NOT
> > pg_check_visibility(oid);
> > or something olong those lines.
>
> Th
Hi,
On 2016-06-06 17:00:19 -0400, Robert Haas wrote:
> 1. I think it is pretty misleading to say that those checks aren't
> reachable any more. It's not like we freeze every page when we mark
> it all-visible.
True. What I mean is that you can't force the checks (and some that I
think should be
On Mon, Jun 6, 2016 at 5:06 PM, Andres Freund wrote:
> On 2016-06-06 16:41:19 -0400, Robert Haas wrote:
>> I really don't understand how you can not weigh in on the original
>> thread leading up to my mid-March commits and say "hey, this needs a
>> better testing tool", and then when you finally g
On 2016-06-06 16:41:19 -0400, Robert Haas wrote:
> I really don't understand how you can not weigh in on the original
> thread leading up to my mid-March commits and say "hey, this needs a
> better testing tool", and then when you finally get around to
> reviewing it in May, I'm supposed to drop ev
On Mon, Jun 6, 2016 at 3:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... I guess I'd prefer #2 to #2.5, #2.5 to #3, and #3 to #1.
>> I really don't like #1 much - I think I'd almost rather do nothing.
>
> FWIW, that's about my evaluation of the alternatives as well. I fear
> that #1 would ge
On Mon, Jun 6, 2016 at 4:27 PM, Andres Freund wrote:
> On 2016-06-06 16:18:19 -0400, Stephen Frost wrote:
>> That could be as simple as a query with the right things installed, or
>> it might be an independent tool, but not having any way to check isn't
>> good. That said, trying to make VACUUM d
On Mon, Jun 6, 2016 at 11:35 AM, Andres Freund wrote:
>> We need a read-only utility which checks that the system is in a correct
>> and valid state. There are a few of those which have been built for
>> different pieces, I believe, and we really should have one for the
>> visibility map, but I d
On Mon, Jun 6, 2016 at 2:35 PM, Andres Freund wrote:
>> > Why would they have to write the complex query? Wouldn't they just
>> > need to run that we wrote for them?
>
> Then write that query. Verify that that query performs halfway
> reasonably fast. Document that it should be run against databa
On Mon, Jun 6, 2016 at 3:26 PM, Tom Lane wrote:
> Robert Haas writes:
> > ... I guess I'd prefer #2 to #2.5, #2.5 to #3, and #3 to #1.
> > I really don't like #1 much - I think I'd almost rather do nothing.
>
> FWIW, that's about my evaluation of the alternatives as well. I fear
> that #1 would
On Mon, Jun 6, 2016 at 4:06 PM, Andres Freund wrote:
>> I do appreciate you reviewing this code, very much, and genuinely, and
>> it would be great if more people wanted to review it.
>
>> But this kind of reads like you think that I'm being a jerk, which I'm
>> trying pretty hard not to be
>
> I
On 2016-06-06 16:18:19 -0400, Stephen Frost wrote:
> That could be as simple as a query with the right things installed, or
> it might be an independent tool, but not having any way to check isn't
> good. That said, trying to make VACUUM do that doesn't make sense to me
> either.
The point is tha
On 06/06/2016 01:38 PM, Tom Lane wrote:
> Also, I'd be a bit inclined to disable the counter reset whenever a column
> list is specified, disregarding the corner case where a list is given but
> it includes all the table's analyzable columns. It doesn't really seem
> worth the effort to account f
Andres, all,
* Andres Freund (and...@anarazel.de) wrote:
> On 2016-06-06 15:16:10 -0400, Robert Haas wrote:
> > On Mon, Jun 6, 2016 at 2:35 PM, Andres Freund wrote:
> > and like you have the right to tell assign me arbitrary work, which I
> > think you don't.
>
> It's not like adding a parameter
Hi,
On 2016-06-06 15:16:10 -0400, Robert Haas wrote:
> On Mon, Jun 6, 2016 at 2:35 PM, Andres Freund wrote:
> >> > Why would they have to write the complex query? Wouldn't they just
> >> > need to run that we wrote for them?
> >
> > Then write that query. Verify that that query performs halfway
I wrote:
> Tomasz Ostrowski writes:
>> I suppose this is a bug - an analyze, which does not analyze all
>> columns, should not reset pg_stat_user_tables(n_mod_since_analyze). What
>> do you think?
> I'm inclined to think that this is a reasonable complaint. A usage
> pattern like that probably
Robert Haas writes:
> ... I guess I'd prefer #2 to #2.5, #2.5 to #3, and #3 to #1.
> I really don't like #1 much - I think I'd almost rather do nothing.
FWIW, that's about my evaluation of the alternatives as well. I fear
that #1 would get a lot of pushback. If we think that something like
"LAT
On Fri, Jun 3, 2016 at 11:13 PM, Robert Haas wrote:
>> I think the workers should stop processing tuples after the tuple queues got
>> detached. This will not only handle above situation gracefully, but will
>> allow to speed up the queries where Limit clause is present on top of Gather
>> node.
On Mon, Jun 6, 2016 at 2:35 PM, Andres Freund wrote:
>> > Why would they have to write the complex query? Wouldn't they just
>> > need to run that we wrote for them?
>
> Then write that query. Verify that that query performs halfway
> reasonably fast. Document that it should be run against databa
On Mon, Jun 6, 2016 at 2:53 PM, Tom Lane wrote:
> Now, if we decide to try to rewrite tlist SRFs as LATERAL, it would likely
> behoove us to do that rewrite before expanding * not after, so that we can
> eliminate the multiple evaluation of foo() that happens currently. (That
> makes it a parser
Alvaro Herrera writes:
> Robert Haas wrote:
>> On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane wrote:
>>> No, because then you get the cross-product of multiple SRFs, not the
>>> run-in-lockstep behavior.
>> Oh. I assumed that was the expected behavior. But, ah, what do I know?
> Lots, I assume --
On Sat, Jun 4, 2016 at 2:57 AM, Amit Kapila wrote:
> In the above change, you are first adding bytes_written and then doing the
> SHM_MQ_DETACHED check, whereas other place the check is done first which
> seems to be right. I think it doesn't matter either way, but it is better
> to be consistent
On Mon, Jun 6, 2016 at 2:31 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
> > On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane wrote:
> > > Robert Haas writes:
> > >> On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote:
> > >>> 2. Rewrite into LATERAL ROWS FROM (srf1(), srf2(), ...). This would
> > >>>
[ redirecting to -hackers ]
Tomasz Ostrowski writes:
> I'm routinely bulk inserting data to a PostgreSQL table and then
> analyzing a single column of the table, because it contains data which
> significantly changes histogram of this column values - for example
> something like adding rows wi
On 2016-06-06 14:24:14 -0400, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Mon, Jun 6, 2016 at 11:44 AM, Andres Freund wrote:
> > >> In terms of diagnostic tools, you can get the VM bits and
> > >> page-level bits using the pg_visibility extension; I wrote it
> > >> p
Robert Haas wrote:
> On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote:
> >>> 2. Rewrite into LATERAL ROWS FROM (srf1(), srf2(), ...). This would
> >>> have the same behavior as before if the SRFs all return the same nu
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jun 6, 2016 at 11:44 AM, Andres Freund wrote:
> >> In terms of diagnostic tools, you can get the VM bits and
> >> page-level bits using the pg_visibility extension; I wrote it
> >> precisely because of concerns like the ones you raise here. I
On Fri, Jun 3, 2016 at 7:58 AM, Korbin Hoffman wrote:
>
> Hi there-
>
> I've attached a small patch exposing HS_COUNT to the user as
> "hstore_length(hstore)". Documentation, upgrade sql files, and a few
> tests are also included.
>
> Almost every hstore function calls HS_COUNT, but I couldn't det
On 06/06/2016 07:40 PM, Tom Lane wrote:
Tomas Vondra writes:
On 06/06/2016 06:15 PM, Tom Lane wrote:
This checks that you found a joinclause mentioning foreignrel. But
foreignrel need have nothing to do with the foreign key; it could be any
table in the query.
I don't follow. How could it
On Mon, Jun 6, 2016 at 11:44 AM, Andres Freund wrote:
>> In terms of diagnostic tools, you can get the VM bits and
>> page-level bits using the pg_visibility extension; I wrote it
>> precisely because of concerns like the ones you raise here. If you
>> want to cross-check the page-level bits agai
On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote:
>>> 2. Rewrite into LATERAL ROWS FROM (srf1(), srf2(), ...). This would
>>> have the same behavior as before if the SRFs all return the same number
>>> of rows, and otherwi
Tomas Vondra writes:
> When it comes to improving multiple (multi-column) foreign keys, I think
> it may get way more complicated that it might seem. What if the foreign
> keys overlap, for example? Or what if the keys go in opposite directions
> (cycle). And so on ...
I think you can group al
Tomas Vondra writes:
> On 06/06/2016 06:15 PM, Tom Lane wrote:
>> This checks that you found a joinclause mentioning foreignrel. But
>> foreignrel need have nothing to do with the foreign key; it could be any
>> table in the query.
> I don't follow. How could it have 'nothing to do with the fore
On 06/06/2016 06:34 PM, Tom Lane wrote:
... BTW, another thought occurred to me yesterday: it seems like the
existing code hasn't thought through its behavior for multiple foreign
keys very carefully. That is, suppose we have both "A.J references B.K"
and "A.X references B.Y", as separate FKs no
On 06/06/2016 06:15 PM, Tom Lane wrote:
Tomas Vondra writes:
On 06/04/2016 08:15 PM, Tom Lane wrote:
* Make RelationGetFKeyList cache a list of ForeignKeyOptInfo structs,
not just constraint OIDs. It's insane that the relcache scans
pg_constraint to collect those OIDs and then the planner re-
"David G. Johnston" writes:
> If the SRFs return a different number of rows the LCM behavior kicks in and
> you get Robert's second result.
Only if the periods of the SRFs are relatively prime. That is, neither of
his examples demonstrate the full weirdness of the current behavior; for
that, you
On 06/06/16 18:30, David G. Johnston wrote:
> To clarify, the present behavior is basically a combination of both of
> Robert's results.
>
> If the SRFs return the same number of rows the first (zippered) result
> is returned without an NULL padding.
>
> If the SRFs return a different number of r
... BTW, another thought occurred to me yesterday: it seems like the
existing code hasn't thought through its behavior for multiple foreign
keys very carefully. That is, suppose we have both "A.J references B.K"
and "A.X references B.Y", as separate FKs not a single multicolumn FK.
The current cod
On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote:
> >> 2. Rewrite into LATERAL ROWS FROM (srf1(), srf2(), ...). This would
> >> have the same behavior as before if the SRFs all return the same number
> >> of rows, and ot
Tomas Vondra writes:
> On 06/04/2016 08:15 PM, Tom Lane wrote:
>> * Make RelationGetFKeyList cache a list of ForeignKeyOptInfo structs,
>> not just constraint OIDs. It's insane that the relcache scans
>> pg_constraint to collect those OIDs and then the planner re-reads all
>> those same rows on e
I'm fine with the code being released under the PostgreSQL license.
Thanks,
Adam
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tomas Vondra writes:
> One of the recent issues with the current design was handling of
> inheritance / appendrels. ISTM the proposed design has the same issue,
> no? What happens if the relations are partitioned?
I haven't thought about inheritance in this proposal. My initial feeling
is that
On Mon, Jun 6, 2016 at 11:45 AM, Bruce Momjian *EXTERN*
wrote:
>
> One more thing --- there was talk of moving some of this into chapter
> 66, but as someone already mentioned, there are no subsections there
> because it is a dedicated topic:
>
> 66. How the Planner Uses Statistics.
> I
I wrote:
> Alvaro Herrera writes:
>> Tom Lane wrote:
>>> Presumably what is happening is that the planner is switching from hash
>>> to sort aggregation.
>> I can't imagine that the server is avoiding hash aggregation on a 1MB
>> work_mem limit for data that's a few dozen of bytes. Is it really
On 2016-06-06 05:34:32 -0400, Robert Haas wrote:
> On Mon, Jun 6, 2016 at 5:11 AM, Michael Paquier
> wrote:
> >> Attached is a sample patch that controls full page vacuum by new GUC
> >> parameter.
> >
> > Don't we want a reloption for that? Just wondering...
>
> Why? Just for consistency? I t
Robert Haas writes:
> On Mon, Jun 6, 2016 at 11:28 AM, Andres Freund wrote:
>> Except that we right now don't have any realistic way to figure out
>> whether this new feature actually does the right thing.
> I just don't see how running VACUUM on the all-frozen pages is going
> to help.
Yes. I
Robert Haas writes:
> On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote:
>> 2. Rewrite into LATERAL ROWS FROM (srf1(), srf2(), ...). This would
>> have the same behavior as before if the SRFs all return the same number
>> of rows, and otherwise would behave differently.
> I thought the idea was t
Tom Lane wrote:
> Alvaro Herrera writes:
> > I can't imagine that the server is avoiding hash aggregation on a 1MB
> > work_mem limit for data that's a few dozen of bytes. Is it really doing
> > that?
>
> Yup:
Aha. Thanks for testing.
> Now that you mention it, this does seem a bit odd, alth
On Mon, Jun 6, 2016 at 11:28 AM, Andres Freund wrote:
> On 2016-06-06 05:34:32 -0400, Robert Haas wrote:
>> On Mon, Jun 6, 2016 at 5:11 AM, Michael Paquier
>> wrote:
>> >> Attached is a sample patch that controls full page vacuum by new GUC
>> >> parameter.
>> >
>> > Don't we want a reloption fo
On Mon, Jun 6, 2016 at 07:19:37AM +, Albe Laurenz wrote:
> Bruce Momjian wrote:
> > OK, updated version attached. I added "potential" to the first
> > paragraph, and added "estimated cost" to the later part, fixed the
> > "cheaper than", and clarified that we add the plan time cost to the
> >
On 2016-06-06 11:37:25 -0400, Robert Haas wrote:
> On Mon, Jun 6, 2016 at 11:28 AM, Andres Freund wrote:
> > Except that we right now don't have any realistic way to figure out
> > whether this new feature actually does the right thing. Which makes
> > testing this *considerably* harder than just
On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote:
> We should consider single and multiple SRFs in a targetlist as distinct
> use-cases; only the latter has got weird properties.
>
> There are several things we could potentially do with multiple SRFs in
> the same targetlist. In increasing order o
Hello!
Why we don't have checksums on clog files.
We have checksum on pg_control, optional checksumming on data files,
some form of checksumming on wal's. But why we don't have any
checksumming on clogs. Corruptions on clogs lead to transaction
visisbility problems and database consistency vi
Kyotaro HORIGUCHI writes:
> At Fri, 03 Jun 2016 09:44:30 -0400, Tom Lane wrote in
> <11515.1464961...@sss.pgh.pa.us>
>> I think that this one:
>>> If the target thread is allocating memory from the heap, the heap
>>> lock will not be released.
>> is potentially a hazard, which is why I made sure
Hi all,
I found that the tab completion for USER MAPPING doesn't work fine.
For example,
The below is no problem.
postgres=# create user[TAB]
user user mapping for
But this doesn't work fine. (Note that there is a white space between
'user' and [TAB])
postgres=# create user [TAB]
ho
On Fri, Jun 3, 2016 at 12:31 PM, Stephen Frost wrote:
>> Stephen, something is smelling wrong in checkExtensionMembership()
>> since 5d58999, an access method does not have ACLs and I would have
>> expected that when this routine is invoked in
>> selectDumpableAccessMethod() the object is not sele
Robert Haas writes:
> I'm intuitively sympathetic to the idea that we should have an option
> for this, but I can't figure out in what case we'd actually tell
> anyone to use it. It would be useful for the kinds of bugs listed
> above to have VACUUM (rebuild_vm) to blow away the VM fork and rebui
On Tue, May 31, 2016 at 2:19 PM, Peter Eisentraut
wrote:
> On 5/31/16 1:47 PM, Jaime Casanova wrote:
>>
>> Are we going to change synchronous_standby_names? Certainly the GUC is
>> not *only* a list of names anymore.
>>
>> synchronous_standby_config?
>> synchronous_standbys (adjust to correct engl
On Thu, Jun 2, 2016 at 4:48 PM, Corey Huinker wrote:
> A while back, there was a push to make COPY gzip-aware. That didn't happen,
> but COPY FROM PROGRAM did, and it scratches the same itch.
>
> I have a similar need, but with file_fdw foreign tables. I have .csv.gz
> files downloaded to the serv
On Thu, Jun 2, 2016 at 12:35 PM, Andreas 'ads' Scherbaum
wrote:
> the TESTING file in src/bin/pg_upgrade talks about a "check.sh script", but
> this seems to be a binary (check) now.
Nope:
[rhaas pgsql]$ git grep -F check.sh
[rhaas pgsql]$
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.c
On Mon, Jun 6, 2016 at 10:18 AM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> My gut feeling on this is to either do nothing or add a VACUUM option
>> (not a GUC, not a reloption) called even_frozen_pages, default false.
>> What is your opinion?
>
> +1 for that approach -- I thought that was alre
Alvaro Herrera writes:
> Tom Lane wrote:
>> Presumably what is happening is that the planner is switching from hash
>> to sort aggregation.
> I can't imagine that the server is avoiding hash aggregation on a 1MB
> work_mem limit for data that's a few dozen of bytes. Is it really doing
> that?
Y
Noah Misch wrote:
> The above-described topic is currently a PostgreSQL 9.6 open item. Álvaro,
> since you committed the patch believed to have created it, you own this open
> item. If some other commit is more relevant or if this does not belong as a
> 9.6 open item, please let us know. Otherw
Tom Lane wrote:
> Alvaro Herrera writes:
> > Michael Paquier wrote:
> >> I know that we guarantee that make installcheck may not work on many
> >> target servers as a lot of tests are very GUC-sensitive, but this
> >> looks a bit oversensitive to me, especially knowing that it is the
> >> only dif
On Fri, Jun 3, 2016 at 11:41 PM, Robert Haas wrote:
> (Status update for Noah: I expect Masahiko Sawada will respond
> quickly, but if not I'll give some kind of update by Monday COB
> anyhow.)
I believe this open item is now closed, unless Andres has more
comments or wishes to discuss any point
Robert Haas wrote:
> My gut feeling on this is to either do nothing or add a VACUUM option
> (not a GUC, not a reloption) called even_frozen_pages, default false.
> What is your opinion?
+1 for that approach -- I thought that was already agreed weeks ago and
the only question was what to name tha
Robert Haas writes:
> On Mon, Jun 6, 2016 at 9:53 AM, Tom Lane wrote:
>> Taking out GUCs is not
>> easier than taking out statement parameters; you risk breaking
>> applications either way.
> Agreed, but that doesn't really answer the question of which one we
> should have, if either. My gut fe
Alvaro Herrera writes:
> Michael Paquier wrote:
>> I know that we guarantee that make installcheck may not work on many
>> target servers as a lot of tests are very GUC-sensitive, but this
>> looks a bit oversensitive to me, especially knowing that it is the
>> only diff generated by the whole tes
Michael Paquier wrote:
> I know that we guarantee that make installcheck may not work on many
> target servers as a lot of tests are very GUC-sensitive, but this
> looks a bit oversensitive to me, especially knowing that it is the
> only diff generated by the whole test suite.
> Don't you think th
On Mon, Jun 6, 2016 at 9:53 AM, Tom Lane wrote:
> Masahiko Sawada writes:
>> On Sat, Jun 4, 2016 at 1:46 PM, Masahiko Sawada
>> wrote:
>>> So other idea is to have GUC parameter, vacuum_even_frozen_page for example.
>>> If this parameter is set true (false by default), we do vacuum whole
>>> ta
On Mon, Jun 6, 2016 at 7:46 AM, Robert Haas wrote:
> On Sat, Jun 4, 2016 at 12:18 AM, Masahiko Sawada
> wrote:
>> Attached updated patch.
>
> The error-checking enhancements here look good to me, except that you
> forgot to initialize totalBytesRead. I've committed those changes
> with a fix fo
On Sat, Jun 4, 2016 at 10:45 PM, David G. Johnston
wrote:
> On Tuesday, March 22, 2016, Merlin Moncure wrote:
>>
>>
>> Anyways, here's the patch with documentation adjustments as promised.
>> I ended up keeping the 'without result' section because it contained
>> useful information about plan cac
Masahiko Sawada writes:
> On Sat, Jun 4, 2016 at 1:46 PM, Masahiko Sawada wrote:
>> So other idea is to have GUC parameter, vacuum_even_frozen_page for example.
>> If this parameter is set true (false by default), we do vacuum whole
>> table forcibly and re-generate visibility map.
>> The advanta
On Mon, Jun 6, 2016 at 7:17 AM, Sridhar N Bamandlapally <
sridhar@gmail.com> wrote:
> Hi
>
> Is there any option in PGPLSQL which can RETURNS table or SETOF rows along
> with an OUT parameter?
>
>
No, there would be no point given the internals of how functions work.
What is it you are tryi
On Sun, Jun 5, 2016 at 4:39 PM, Jim Nasby wrote:
> I'm pretty sure this is a typo...
Sure is. Thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
On Sat, Jun 4, 2016 at 12:18 AM, Masahiko Sawada wrote:
> Attached updated patch.
The error-checking enhancements here look good to me, except that you
forgot to initialize totalBytesRead. I've committed those changes
with a fix for that problem and will look at the rest of this
separately.
--
Hi
Is there any option in PGPLSQL which can RETURNS table or SETOF rows along
with an OUT parameter?
please
Thanks
Sridhar
OpenText
On Mon, Jun 6, 2016 at 6:34 PM, Robert Haas wrote:
> On Mon, Jun 6, 2016 at 5:11 AM, Michael Paquier
> wrote:
>>> Attached is a sample patch that controls full page vacuum by new GUC
>>> parameter.
>>
>> Don't we want a reloption for that? Just wondering...
>
> Why? Just for consistency? I thi
How about silencing the workers on termination?
# Build on Windows (with VC?) is very time consuming...
At Fri, 03 Jun 2016 09:44:30 -0400, Tom Lane wrote in
<11515.1464961...@sss.pgh.pa.us>
> Kyotaro HORIGUCHI writes:
> > For sure, any of the "dangers" of TerminateThread don't matter
> > for
On Sat, Jun 4, 2016 at 1:53 AM, Robert Haas wrote:
>
> On Thu, May 12, 2016 at 2:07 PM, Tom Lane wrote:
> >> Err, wow. That makes my head hurt. Can you explain why this case
> >> only arises for appendrel children, and not for plain rels?
> >
> > Well, plain rels only output Vars ;-)
>
> Hmm.
On Mon, Jun 6, 2016 at 5:11 AM, Michael Paquier
wrote:
>> Attached is a sample patch that controls full page vacuum by new GUC
>> parameter.
>
> Don't we want a reloption for that? Just wondering...
Why? Just for consistency? I think the bigger question here is
whether we need to do anything a
On Mon, Jun 6, 2016 at 5:44 PM, Masahiko Sawada wrote:
> On Sat, Jun 4, 2016 at 1:46 PM, Masahiko Sawada wrote:
>> On Sat, Jun 4, 2016 at 12:59 AM, Robert Haas wrote:
>>> On Fri, Jun 3, 2016 at 11:21 AM, Masahiko Sawada
>>> wrote:
> Can you submit that part as a separate patch?
A
1 - 100 of 104 matches
Mail list logo
