Thanks a lot.
On Fri, Sep 16, 2016 at 7:07 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
>>> I'd suggest that this is parallel to nodeToString() and therefore
>>> (a) should be placed beside it,
>
>> Done. Added it after nodeToString().
>
> Pushed, thanks.
>
> regards, tom
Ashutosh Bapat writes:
>> I'd suggest that this is parallel to nodeToString() and therefore
>> (a) should be placed beside it,
> Done. Added it after nodeToString().
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
>
> I'd suggest that this is parallel to nodeToString() and therefore
> (a) should be placed beside it,
Done. Added it after nodeToString().
> (b) should be named like it,
> bmsToString() perhaps,
bmsToString() is fine. Used that name.
> and (c) should look more like it internally.
>
Done.
I
Robert Haas writes:
> This seems like a very complicated mechanism of substituting for a
> very simple patch.
Well, if we're gonna do it, then let's just do it, but please let's
have a patch that doesn't look like somebody's temporary debugging kluge.
I'd suggest that this is parallel to nodeToS
On Thu, Sep 15, 2016 at 7:55 PM, Pavan Deolasee
wrote:
>
> (lldb) script print print_bms_members(lldb.frame.FindVariable ("a"))
> nwords = 1 bitmap: 0x200
>
>
Or even this if lldb.frame.FindVariable() is pushed inside the function:
(lldb) script print print_bms_members('a')
nwords = 1 bitmap: 0x
On Thu, Sep 15, 2016 at 7:38 PM, Robert Haas wrote:
>
>
> This seems like a very complicated mechanism of substituting for a
> very simple patch.
I don't have objection to the patch per se. The point of posting this was
just to share other mechanisms that exists. BTW advantage of using debugger
On Wed, Sep 14, 2016 at 8:01 AM, Pavan Deolasee
wrote:
> On Wed, Sep 14, 2016 at 3:46 PM, Pavan Deolasee
> wrote:
>> lately I'm using LVM debugger (which probably does not have something
>> equivalent),
>
>
> And I was so clueless about lldb's powerful scripting interface. For
> example, you can
On Wed, Sep 14, 2016 at 8:45 PM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>> Ashutosh Bapat writes:
>> > While working on partition-wise join, I had to examine Relids objects
>> > many times. Printing the Bitmapset::words[] in binary format and then
>> > inferring the relids takes time and is erro
>> Alvaro Herrera writes:
>>> I don't understand. Why don't you just use "call pprint(the bitmapset)"
>>> in the debugger?
>>
>> Bitmapsets aren't Nodes, so pprint doesn't work directly on them.
>> I usually find that I can pprint some node containing the value(s)
>> I'm interested in, but maybe
On Thu, Sep 15, 2016 at 2:58 PM, Ashutosh Bapat
wrote:
> On Wed, Sep 14, 2016 at 5:31 PM, Pavan Deolasee
> wrote:
>> The complete API reference is available here
>> http://lldb.llvm.org/python_reference/index.html
>>
>> Looks like an interesting SoC project to write useful lldb/gdb scripts to
>>
On Wed, Sep 14, 2016 at 5:31 PM, Pavan Deolasee
wrote:
>
> On Wed, Sep 14, 2016 at 3:46 PM, Pavan Deolasee
> wrote:
>>
>>
>>
>> lately I'm using LVM debugger (which probably does not have something
>> equivalent),
>
>
> And I was so clueless about lldb's powerful scripting interface. For
> examp
On 2016/09/15 0:04, Tom Lane wrote:
> Alvaro Herrera writes:
>> I don't understand. Why don't you just use "call pprint(the bitmapset)"
>> in the debugger?
>
> Bitmapsets aren't Nodes, so pprint doesn't work directly on them.
> I usually find that I can pprint some node containing the value(s)
>
Tom Lane wrote:
> Ashutosh Bapat writes:
> > While working on partition-wise join, I had to examine Relids objects
> > many times. Printing the Bitmapset::words[] in binary format and then
> > inferring the relids takes time and is error prone.
>
> FWIW, I generally rely on pprint() to look at pl
Ashutosh Bapat writes:
> While working on partition-wise join, I had to examine Relids objects
> many times. Printing the Bitmapset::words[] in binary format and then
> inferring the relids takes time and is error prone.
FWIW, I generally rely on pprint() to look at planner data structures
from t
Alvaro Herrera writes:
> I don't understand. Why don't you just use "call pprint(the bitmapset)"
> in the debugger?
Bitmapsets aren't Nodes, so pprint doesn't work directly on them.
I usually find that I can pprint some node containing the value(s)
I'm interested in, but maybe that isn't working
Ashutosh Bapat wrote:
> Hi All,
> While working on partition-wise join, I had to examine Relids objects
> many times. Printing the Bitmapset::words[] in binary format and then
> inferring the relids takes time and is error prone. Instead I wrote a
> function bms_to_char() which allocates a StringIn
On Wed, Sep 14, 2016 at 3:46 PM, Pavan Deolasee
wrote:
>
>
> lately I'm using LVM debugger (which probably does not have something
> equivalent),
>
And I was so clueless about lldb's powerful scripting interface. For
example, you can write something like this in bms_utils.py:
import lldb
def
On Wed, Sep 14, 2016 at 3:43 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> Hi All,
> While working on partition-wise join, I had to examine Relids objects
> many times. Printing the Bitmapset::words[] in binary format and then
> inferring the relids takes time and is error prone.
Hi All,
While working on partition-wise join, I had to examine Relids objects
many times. Printing the Bitmapset::words[] in binary format and then
inferring the relids takes time and is error prone. Instead I wrote a
function bms_to_char() which allocates a StringInfo, calls
outBitmapset() to deco
19 matches
Mail list logo
