Re: Bitmask trickiness - Mailing list pgsql-general

From Howard Rogers
Subject Re: Bitmask trickiness
Date
Msg-id AANLkTin4YXqftMsuoUJ117w6JRz65lJIhvES3dYYN0vF@mail.gmail.com
Whole thread Raw
In response to Re: Bitmask trickiness  (Scott Marlowe <scott.marlowe@gmail.com>)
Responses Re: Bitmask trickiness
Re: Bitmask trickiness
List pgsql-general
On Fri, Jul 23, 2010 at 3:02 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>> If you mean, did I read the bit in the doco where it said nothing at
>> all in the 'these are great advantages' style I've just described, but
>> instead makes the fairly obvious point that a bit string takes 8 bits
>> to store a group of 8 bits (well, stone me!!)
>
> Wow, I'm surprised you get any help with your attitude.  I posted a
> link and asked a question and right up front got my head handed to me.
>
> To quote:  "Why on Earth would I want to store this sort of stuff in a
> bit string?!
>
> I don't know about you, but I find looking at 21205 a darn'd site
> easier than staring blankly at 101001011010101!!"
>
> Like I'd somehow bitten your hand when I asked my question.

That is not attitude, Scott. That is me asking a question riddled with
rhetorical exclamations.

You asked me why I wasn't using bitstrings. I asked why on Earth I
would. That's all. The only "attitude" you could reasonably detect
there, I think, is surprise that when I ask a precise technical
question, someone would feel it fair game to question the entire basis
of a database design about which they know extremely little (which is
not their -or your- fault, because you only get to know the details I
include in the question, after all. Fact remains, on such slim
foundations, I wouldn't build a mountain of questioning the reasons
for or behind someone else's work).

>> PLUS has extra overhead,
>> then yes, I did read that part of your first link... and nevertheless
>> concluded that, overall, there is... er, some extra overhead in
>> storing bitstrings.
>
> Well, your initial answer certainly didn't give ANY idea that you'd
> read that page.

It neither gave the impression I had, nor gave any indication that I
hadn't! That's the point: you've assumed something you needn't have.

>> So what precisely about that first article, which I did indeed read,
>> would you have expected to lead me to the conclusion that I'd SAVE
>> significant amounts of space or find some other technically-compelling
>> reason for switching?
>
> I didn't expect such.  I asked why you weren't using them, and gave
> you some links to read on it.  It clearly states that bit strings use
> a bit per bit, plus some overhead.  Now, I had no idea if you were
> dealing with bigints and 60 bit strings or 5 bit strings.  In fact,
> you did little to really describe your project and preferences in your
> post.  Which is why my response was short and concise, I had little to
> go on.

Exactly. Now, I grant you it's difficult when you can't see me; when
there's only the written word to go on; when you don't know my
personal modes of expression, nor I yours. But that's precisely why I
wouldn't answer a narrowly-scoped technical question with even a hint
of a suggestion that the entire basis of the question was suspect: I
didn't give you any details of my project or preferences, because I
was asking a precise, narrowly-focussed question about getting one
specific result with one specific query structure.

Honestly, when I want general consulting, I pay for it. You really
don't have to try and give it away for free.

>> My point is that there's nothing much in it, storage-wise, either way.
>
> Well, there is the fact that bit strings can restrict the size of the
> entry so you don't accidentally get an int stored that's got more bits
> than your model can handle.

Well, that's fortunately not something I have to worry about.
Somewhere around the 192th bit, I'll start panicking. When I've only
got 15 of the blighters to worry about, I think I'll cope.

>There's also the issue that if / when you
> ever get close to the last bit in an int bitstring may behave oddly
> because of sign issues.

And also something I don't have to worry about.

>> So there's no compelling technical reason to switch.
>
> I never said there was.  I simply asked a question, and got my hand bitten.

No, you got a question asked back at you: *WHY* would you think I
should be using a bitstring? It was an honest question, basically
wondering if there's something about bitstrings that make them such a
great idea. It's not a data type Oracle users are greatly familiar
with, you see.

>> And without a
>> technically-compelling reason, the rest of the post I was referring to
>> simply boiled down, as far as I could tell, to a matter of personal
>> preference. No less valid for that, of course. But ultimately, not
>> something that would hold much sway with me.
>
> Sure, fine, whatever you want.  I wasn't trying to convince you either
> way.  I do think using the right type for the job makes more sense,
> but again, it's personal preference.

Indeed. Although in this case, it's not even the right type for the job.

>>>> But simply saying "your design is broken... wooooo!" might well scare
>>>> the children, but doesn't really do anything for me, because I know
>>>> for a certainty that it's not broken at all.
>>>
>>> I asked if there was a reason you were avoiding bit strings.  Hardly a
>>> "your design is broken" point.
>>
>> I'm getting a bit fed up of this thread now. It wasn't YOU that ever
>> said 'the design is broken', and I never suggested it was. That was
>> Peter Hunsberger, about three posts up in the thread, who wrote "In
>> that case your database design is fundamentally broken."
>
> Well, pardon me for misunderstanding.  I'll stop the conversation
> after this message too.   you do realize that paragraph immediately
> followed the one referring to my post.

Well, the line *I* wrote that "simply saying "your design is broken...
wooooo!" might well scare the children..." and so on, was the SECOND
paragraph of a reply I made to a post made by Peter. It came
immediately after a paragraph *Peter* had written (the first line of
which was 'your design is broken'.  And that came immediately after a
line I'd written that said "It's not an integer. It's an encoded bit
of magic". So I make that at least four paragraphs of content before
your stuff even gets close...

Maybe we read this stuff in different readers that thread differently?

>
>> If you're going to take umbrage at something, please take umbrage at
>> things that were actually directed at you in the first place!
>
> Wait a second, do I work for you or something?  Cause I could swear
> this was a forum where equals discussed issues with each other.

It would be nice if it was. Instead, it seems to be a place where you
get to question all sorts of things you self-confessedly know not much
about and then blame me for having 'attitude' when I ever-so-gently
try to point out that learning about your personal preferences was not
why I was writing here!

>I'll
> try to do better from now on when I provide free advice to people.  I
> wouldn't want to disappoint you.

All I said was, please try to only take offence at things which you
could genuinely take offence at! The comment about 'design is broken'
was made by Peter, not you. My firm -but hopefully polite- rebuttal of
the idea the design is broken was aimed at him, not you. Therefore,
for you to pick up on the point as say "I hardly meant your design was
broken" was something of a complete non sequiteur on your part, I
felt.

>>> You've now said why you are not using
>>> the type that was designed to handle bit strings for bit strings.
>>>
>>> I personally would store them as bit strings and change representation
>>> for users.
>>
>> I'm a user, too. I get to see this stuff every time I do a select
>> statement. At the command line. Which I use a lot.
>
> I guess 20 years of teaching and working on digital electronics and
> assembly code left me quite a bit more comfortable with binary
> strings.  I'd be quite comfortable with them on the command line.

Oh, come now. A veiled appeal to authority... I'm sure you can do
better than that. I've been teaching and working with databases since
1987 if we're trading 'years of experience'.

>>> There are some issues that come up if your bit strings are
>>> long enough to get close to the last bit in an integer (also mentioned
>>> on the links I posted that didn't get read).
>>
>> Don't make false assumptions about other people, please. You don't
>> know what I read or didn't read.
>
> No I didn't.  But it certainly seemed to me like you hadn't.

Which is an assumption on your part. As I said...

From now
> on I'll only comment on exactly what you've posted.  I'll go one
> better and just stop after this post.

An excellent idea for us both, I think.

>> Just because you didn't make a
>> compelling technical argument in favour of bitstrings doesn't mean I
>> didn't read the article you linked to ...that also didn't make a
>> compelling technical argument in favour of bitstrings.
>
> Who's job is it to understand this software and make compelling
> arguments?  Again, I'm not a paid consultant, I don't spend hours each
> day carefully crafting arguments to make you happy.  I asked one
> freakin question, gave two links and got nothing but attitude.

You asked one question, got an answer, and have leapt to conclusions
ever since.

> I'd be ever so happy if you took your attitude and went back to Oracle use.

Your right and privilege, naturally.

>>> But other than that it
>>> should work fine.
>>
>> Yes, I know. I've only been using this technique for five years on
>> Oracle! I would be very surprised indeed if it wasn't transferrable to
>> PostgreSQL.
>
> Me too.  But I think you'd be way happier on Oracle.

I am. It's because I'm learning, and that's always a tricky
experience, and one is generally happier with what one is comfortable
with. But I actually think PostgreSQL is a spectacularly good RDBMS,
and I'll persist, if that's OK by you. When I need help, I'll ask for
it. If I'm given it, I'll be grateful for it. When I'm offered
personal opinion on things I don't need assistance with, I'll try and
deflect it as nicely as I know how. Whether someone will take the hint
or not is another matter, I guess.

>> Still doesn't answer the precise, specific technical question I
>> actually asked, though, does it?!
>
> Which was answered by Stephen Cook was it not?  I.e. use plain old equals?

Maybe I should assume you haven't read the thread, then?! God knows
what that answer even actually meant, but hopefully you read my reply
where I pointed out that it's no answer at all. 21205 & 4098 = what,
precisely? Never mind: another rhetorical question. Plain old equals
doesn't come close.

>> And since there is indeed no technical content in these continued
>> to-and-fro posts, I'll be leaving it there, if that's OK.
>
> That would be great.  Hope to not be seeing you around.

As I say, it's your right and privilege to feel that way. And if it
makes you feel any happier, please feel free to ignore any future
posts I might make. Regrettable, really, since I had nothing but
gratitude for your original post, whatever you might think.

Regards
HJR

pgsql-general by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: optimizing daily data storage in Pg
Next
From: Stephen Cook
Date:
Subject: Re: Bitmask trickiness