On Wed, Jan 25, 2017 at 2:53 PM, Michael Paquier
wrote:
> The latest patch available still applies, one person has added his
> name (John G) in October though there have been no reviews. There have
> been a couple of arguments against this patch, and the thread has had
> no activity for the last m
On Mon, Dec 5, 2016 at 11:32 AM, Haribabu Kommi
wrote:
>
>
> On Tue, Nov 15, 2016 at 1:17 PM, Noah Misch wrote:
>>
>> On Mon, Nov 14, 2016 at 10:21:53AM -0800, Peter Geoghegan wrote:
>> > BTW, I recently noticed that the latest version of Valgrind, 3.12,
>> > added this new feature:
>> >
>> > * M
On Tue, Nov 15, 2016 at 1:17 PM, Noah Misch wrote:
> On Mon, Nov 14, 2016 at 10:21:53AM -0800, Peter Geoghegan wrote:
> > BTW, I recently noticed that the latest version of Valgrind, 3.12,
> > added this new feature:
> >
> > * Memcheck:
> >
> > - Added meta mempool support for describing a cust
On Mon, Nov 14, 2016 at 10:21:53AM -0800, Peter Geoghegan wrote:
> BTW, I recently noticed that the latest version of Valgrind, 3.12,
> added this new feature:
>
> * Memcheck:
>
> - Added meta mempool support for describing a custom allocator which:
> - Auto-frees all chunks assuming that
On Mon, Nov 14, 2016 at 10:17 AM, Andres Freund wrote:
> I think so, yes. IIRC I discussed it with Noah and Peter G. at a
> conference recently. We'd basically mark the content of shared buffers
> inaccessible at backend startup, and mark it accessible whenever a
> PinBuffer() happens, and then in
On 2016-11-14 13:12:28 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-11-14 12:32:53 -0500, Tom Lane wrote:
> >> Basically my concern is that this restriction isn't documented anywhere
> >> and I'm not entirely certain it's been adhered to everywhere. I'd feel
> >> much better about i
Andres Freund writes:
> On 2016-11-14 12:32:53 -0500, Tom Lane wrote:
>> Basically my concern is that this restriction isn't documented anywhere
>> and I'm not entirely certain it's been adhered to everywhere. I'd feel
>> much better about it if there were some way we could verify that.
> Would
On 2016-11-14 12:32:53 -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 11/14/2016 06:18 PM, Tom Lane wrote:
> >> You're implicitly assuming that a scan always returns its results in the
> >> same slot, and that no other slot could contain a copy of that data, but
> >> there is no guaran
On Mon, Nov 14, 2016 at 9:22 AM, Heikki Linnakangas wrote:
> I think that difference in the API is exactly what caught Peter by surprise
> and led to bug #14344. And I didn't see it either, until you two debugged
> it.
That is accurate, of course.
--
Peter Geoghegan
--
Sent via pgsql-hacker
Heikki Linnakangas writes:
> On 11/14/2016 06:18 PM, Tom Lane wrote:
>> You're implicitly assuming that a scan always returns its results in the
>> same slot, and that no other slot could contain a copy of that data, but
>> there is no guarantee of either. See bug #14344 and d8589946d for a
>> pr
On 11/14/2016 06:18 PM, Tom Lane wrote:
Robert Haas writes:
On Mon, Nov 14, 2016 at 10:23 AM, Tom Lane wrote:
I don't believe Andres' claim anyway. There are certainly cases where an
allegedly-valid slot could be pointing at garbage, but table scans aren't
one of them, precisely because of t
On Mon, Nov 14, 2016 at 11:18 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Nov 14, 2016 at 10:23 AM, Tom Lane wrote:
>>> I don't believe Andres' claim anyway. There are certainly cases where an
>>> allegedly-valid slot could be pointing at garbage, but table scans aren't
>>> one of them
Robert Haas writes:
> On Mon, Nov 14, 2016 at 10:23 AM, Tom Lane wrote:
>> I don't believe Andres' claim anyway. There are certainly cases where an
>> allegedly-valid slot could be pointing at garbage, but table scans aren't
>> one of them, precisely because of the pin held by the slot. It woul
On Mon, Nov 14, 2016 at 10:23 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Nov 12, 2016 at 10:28 AM, Andres Freund wrote:
>>> On 2016-08-30 07:38:10 -0400, Tom Lane wrote:
I think this is probably wrong, or at least very dangerous to remove.
The reason for the feature is that t
On 2016-11-14 10:09:02 -0500, Robert Haas wrote:
> On Sat, Nov 12, 2016 at 10:28 AM, Andres Freund wrote:
> > On 2016-08-30 07:38:10 -0400, Tom Lane wrote:
> >> Heikki Linnakangas writes:
> >> > While profiling some queries and looking at executor overhead, I
> >> > realized that we're not making
Robert Haas writes:
> On Sat, Nov 12, 2016 at 10:28 AM, Andres Freund wrote:
>> On 2016-08-30 07:38:10 -0400, Tom Lane wrote:
>>> I think this is probably wrong, or at least very dangerous to remove.
>>> The reason for the feature is that the slot may continue to point at
>>> the tuple after the
On Sat, Nov 12, 2016 at 10:28 AM, Andres Freund wrote:
> On 2016-08-30 07:38:10 -0400, Tom Lane wrote:
>> Heikki Linnakangas writes:
>> > While profiling some queries and looking at executor overhead, I
>> > realized that we're not making much use of TupleTableSlot's ability to
>> > hold a buffer
On 2016-08-30 07:38:10 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > While profiling some queries and looking at executor overhead, I
> > realized that we're not making much use of TupleTableSlot's ability to
> > hold a buffer pin. In a SeqScan, the buffer is held pinned by the
> > under
On Wed, Aug 31, 2016 at 6:03 AM, Andres Freund wrote:
> On 2016-08-30 21:59:44 +0100, Greg Stark wrote:
>> On Tue, Aug 30, 2016 at 11:12 AM, Heikki Linnakangas wrote:
>> > While profiling some queries and looking at executor overhead, I realized
>> > that we're not making much use of TupleTableSl
On 2016-08-30 21:59:44 +0100, Greg Stark wrote:
> On Tue, Aug 30, 2016 at 11:12 AM, Heikki Linnakangas wrote:
> > While profiling some queries and looking at executor overhead, I realized
> > that we're not making much use of TupleTableSlot's ability to hold a buffer
> > pin. In a SeqScan, the buf
On Tue, Aug 30, 2016 at 11:12 AM, Heikki Linnakangas wrote:
> While profiling some queries and looking at executor overhead, I realized
> that we're not making much use of TupleTableSlot's ability to hold a buffer
> pin. In a SeqScan, the buffer is held pinned by the underlying heap-scan
> anyway.
Hi,
On 2016-08-30 13:12:41 +0300, Heikki Linnakangas wrote:
> While profiling some queries and looking at executor overhead, I realized
> that we're not making much use of TupleTableSlot's ability to hold a buffer
> pin.
FWIW, I came to a similar conclusion, while working on passing around
making
On 08/30/2016 02:38 PM, Tom Lane wrote:
Heikki Linnakangas writes:
While profiling some queries and looking at executor overhead, I
realized that we're not making much use of TupleTableSlot's ability to
hold a buffer pin. In a SeqScan, the buffer is held pinned by the
underlying heap-scan anywa
Heikki Linnakangas writes:
> While profiling some queries and looking at executor overhead, I
> realized that we're not making much use of TupleTableSlot's ability to
> hold a buffer pin. In a SeqScan, the buffer is held pinned by the
> underlying heap-scan anyway. Same with an IndexScan, and t
24 matches
Mail list logo
