On Sat, Dec 15, 2018 at 09:51:31AM -0500, Tom Lane wrote:
> Alvaro Herrera writes:
>> Oh, we already have it! Sorry, I overlooked it. With that, it seems
>> the patch is fairly simple ... I wonder about the locking implications
>> in autovacuum, though -- the value is set in backends without acq
On Sat, Dec 15, 2018 at 01:04:00PM +0300, Sergei Kornilov wrote:
> Seems we erroneously moved this thread to next CF:
> https://commitfest.postgresql.org/21/1842/
> Can you close this entry?
Robert has committed a patch to refactor a bit the list contruction of
RelationBuildPartitionDesc thanks to
On Fri, Dec 14, 2018 at 09:00:58AM -0300, Alvaro Herrera wrote:
> On 2018-Dec-14, Peter Eisentraut wrote:
>> Do you happen to have a link for that? I didn't find anything.
The message I was thinking about is close to here:
https://www.postgresql.org/message-id/20121210152856.gc16...@awork2.anaraz
Erik Rijkers writes:
> I have noticed that since ffa4cbd623, a foreign table that pulls data
> from a PROGRAM (in this case an unzip call) will fail if there is a
> LIMIT on the SELECT
> (while succeeding without LIMIT). Below is an example.
Um ... this example works for me, in both HEAD and v11
Hello,
I have noticed that since ffa4cbd623, a foreign table that pulls data
from a PROGRAM (in this case an unzip call) will fail if there is a
LIMIT on the SELECT
(while succeeding without LIMIT). Below is an example.
(Table size matters, so larger machines than mine may need more than
those
On Fri, Dec 14, 2018 at 9:47 PM Andres Freund wrote:
> On 2018-12-14 21:39:48 +0300, Alexander Korotkov wrote:
> > If so, then can we just give up with that? That is before setting
> > kill_prior_tuple = true, prune corresponding heap tuples.
>
> That'd require WAL logging such changes, which'd b
Vijaykumar Jain writes:
> I was just playing with exploring joins and plans i came across this
> create table t1(a int);
> create table t2(a int);
> insert into t1 select (x % 10) from generate_series(1, 10) x;
> insert into t2 select (x % 100) from generate_series(1, 10) x;
> ...
> select
Andres Freund writes:
> On 2018-12-15 14:43:49 -0500, Tom Lane wrote:
>> Note that timestamp_lt etc don't actually need any special case for
>> infinity, and we could hope that the infinity representation for interval
>> makes it possible to likewise not special-case it in interval comparisons.
>>
Hi,
On 2018-12-15 14:43:49 -0500, Tom Lane wrote:
> Note that timestamp_lt etc don't actually need any special case for
> infinity, and we could hope that the infinity representation for interval
> makes it possible to likewise not special-case it in interval comparisons.
> But I think it's silly
Hi,
On 2018-12-15 10:45:21 -0500, Tom Lane wrote:
> Andrew Gierth writes:
> > "Andres" == Andres Freund writes:
> >> I think it'd probably good to add accessors for value/nullness in
> >> arguments that hide the difference between >> sake of extension authors. Would probably mostly make sense i
Andres Freund writes:
> On 2018-12-15 09:44:50 -0500, Tom Lane wrote:
>> Yes. The performance argument has some merit for cases like int4 and
>> float8, where the "useful work" might be as small as one machine
>> instruction. But timestamp and interval operations are, for the most
>> part, prett
Hi,
On 2018-12-15 20:15:12 +0100, Dmitry Dolgov wrote:
> > On Tue, Dec 11, 2018 at 3:13 AM Andres Freund wrote:
> >
> > Further tasks I'm not yet planning to tackle, that I'd welcome help on:
> > - pg_dump support
> > - pg_upgrade testing
> > - I think we should consider removing HeapTuple->t_tab
Hi,
On 2018-12-15 09:44:50 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 14 Dec 2018 at 22:24, Robert Haas wrote:
> >> So essentially I think supporting special values like infinity boils
> >> down to trading away some small amount of performance -- more likely
> >> to be noticeable w
> On Tue, Dec 11, 2018 at 3:13 AM Andres Freund wrote:
>
> Further tasks I'm not yet planning to tackle, that I'd welcome help on:
> - pg_dump support
> - pg_upgrade testing
> - I think we should consider removing HeapTuple->t_tableOid, it should
> imo live entirely in the slot
I'm a bit confus
I wrote:
> While fooling with the idea of making type "name" collation
> aware, it occurred to me that there's a better, more general
> answer, which is to insist that collation-aware system catalog
> columns must be marked with C collation. This rule would apply
> without modification to both "te
Awhile back we noticed that a couple of system catalogs had
acquired indexes on "text" columns, which were unsafe because
their sort order was collation-dependent, so that cloning
template0 with a different database collation could yield
broken indexes. We fixed this in commit 0b28ea79 with a
bit
I wrote:
> Andres Freund writes:
>> On 2018-12-14 14:25:30 -0500, Tom Lane wrote:
>>> Now, it's certainly true that nameeq() doesn't need a collation spec
>>> today, any more than texteq() does, because both types legislate that
>>> equality is bitwise. But if we leave ExecBuildGroupingEqual like
On 12/14/18 4:32 PM, Tomas Vondra wrote:
>
>
> On 12/14/18 4:21 PM, Tom Lane wrote:
>> Tomas Vondra writes:
>>> ... I propose to extend EXPLAIN output with an additional option, which
>>> would include information about modified GUCs in the execution plan
>>> (disabled by default, of course):
Andrew Gierth writes:
> "Andres" == Andres Freund writes:
>> I think it'd probably good to add accessors for value/nullness in
>> arguments that hide the difference between > sake of extension authors. Would probably mostly make sense if we
>> backpatched those for compatibility.
> Speaking as a
On 14/12/2018 19:44, Robert Haas wrote:
> I'm showing up very late to the party here, but I like option 1 best.
> I feel like the SQL standard has a pretty clear idea that NULL is how
> you represent a value is unknown, which shows up in a lot of places.
> Deciding that we're going to use a differe
Alvaro Herrera writes:
> On 2018-Dec-15, Michael Paquier wrote:
>> Isn't that what tempNamespaceId can be used for in PGPROC now? The flag
>> would be set only when a backend creates a new temporary schema so as it
>> can be tracked as the owner of the schema.
> Oh, we already have it! Sorry, I
Simon Riggs writes:
> On Fri, 14 Dec 2018 at 22:24, Robert Haas wrote:
>> So essentially I think supporting special values like infinity boils
>> down to trading away some small amount of performance -- more likely
>> to be noticeable with JIT -- for some amount of possible programmer
>> convenie
On 14/12/2018 16:56, Stephen Frost wrote:
> Greetings,
>
> * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
>> On 11/23/18 8:03 PM, Stephen Frost wrote:
>>> * FabrÃzio de Royes Mello (fabriziome...@gmail.com) wrote:
On Fri, Nov 23, 2018 at 4:13 PM Petr Jelinek
wrote:
>> If caref
On 14/12/2018 16:38, Stephen Frost wrote:
> Greetings,
>
> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
>> On 23/11/2018 03:02, Stephen Frost wrote:
>>> * Euler Taveira (eu...@timbira.com.br) wrote:
2018-02-28 21:54 GMT-03:00 Craig Ringer :
> Good idea. I haven't read this yet, bu
On 2018-Dec-15, Michael Paquier wrote:
> On Fri, Dec 14, 2018 at 11:06:32PM -0300, Alvaro Herrera wrote:
> > I did propose in my OP the idea of a PGPROC boolean flag that indicates
> > whether the temp namespace has been set up. If not, have autovac remove
> > those tables. I like this option be
Hello
> OK. Rebased again, and committed (although I forgot to include a link
> to this discussion - sorry about that).
Seems we erroneously moved this thread to next CF:
https://commitfest.postgresql.org/21/1842/
Can you close this entry?
regards, Sergei
On Fri, 14 Dec 2018 at 22:24, Robert Haas wrote:
> So essentially I think supporting special values like infinity boils
> down to trading away some small amount of performance -- more likely
> to be noticeable with JIT -- for some amount of possible programmer
> convenience. Some people may thi
On Tue, Dec 11, 2018 at 12:47 PM Andres Freund wrote:
> Hi,
>
> Thanks for these changes. I've merged a good chunk of them.
>
Thanks.
> On 2018-11-16 12:05:26 +1100, Haribabu Kommi wrote:
> > diff --git a/src/backend/access/heap/heapam_handler.c
> b/src/backend/access/heap/heapam_handler.c
> >
28 matches
Mail list logo
