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
> >
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
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 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
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 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
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
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
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
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
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
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:
> 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
> 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
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
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 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 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
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.
>>
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
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
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
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
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
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 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
28 matches
Mail list logo
