On Tue, Aug 28, 2018 at 8:02 PM, Tom Lane wrote:
> I think this argument is a red herring TBH. The example Robert shows is
> of *zero* interest for dynahash or catcache, unless it's taking only the
> low order 3 bits of the OID for the bucket number. But actually we'll
> increase the table size
Thomas Munro writes:
> On Wed, Aug 29, 2018 at 11:05 AM Thomas Munro
> wrote:
>> On Wed, Aug 29, 2018 at 2:09 AM Robert Haas wrote:
>>> rhaas=# create table a (x serial primary key);
>>> CREATE TABLE
>>> rhaas=# create table b (x serial primary key);
>>> CREATE TABLE
>>> rhaas=# select
On Wed, Aug 29, 2018 at 11:05 AM Thomas Munro
wrote:
> On Wed, Aug 29, 2018 at 2:09 AM Robert Haas wrote:
> > rhaas=# create table a (x serial primary key);
> > CREATE TABLE
> > rhaas=# create table b (x serial primary key);
> > CREATE TABLE
> > rhaas=# select 'a'::regclass::oid,
On Wed, Aug 29, 2018 at 2:09 AM Robert Haas wrote:
> On Mon, Aug 27, 2018 at 10:12 PM, Andres Freund wrote:
> > Huh? Oids between, say, 1 and FirstNormalObjectId, are vastly more
> > common than the rest. And even after that, individual tables get large
> > clusters of sequential values to the
On Wed, Aug 29, 2018 at 1:37 AM Tom Lane wrote:
> Andres Freund writes:
> > On 2018-08-28 14:45:49 +1200, Thomas Munro wrote:
> >> Yeah, it would be a terrible idea as a general hash function for use
> >> in contexts where the "avalanche effect" assumption is made about
> >> information being
On Mon, Aug 27, 2018 at 10:12 PM, Andres Freund wrote:
> Huh? Oids between, say, 1 and FirstNormalObjectId, are vastly more
> common than the rest. And even after that, individual tables get large
> clusters of sequential values to the global oid counter.
Sure, but if you get a large cluster of
Andres Freund writes:
> On 2018-08-28 14:45:49 +1200, Thomas Munro wrote:
>> Yeah, it would be a terrible idea as a general hash function for use
>> in contexts where the "avalanche effect" assumption is made about
>> information being spread out over the bits (the HJ batching code
>> wouldn't
On 2018-08-28 14:45:49 +1200, Thomas Munro wrote:
> On Tue, Aug 28, 2018 at 2:26 PM Tom Lane wrote:
> > Andres Freund writes:
> > > On 2018-08-28 13:50:43 +1200, Thomas Munro wrote:
> > >> What bad thing would happen if we used OIDs directly as hash values in
> > >> internal hash tables (that
On Tue, Aug 28, 2018 at 2:26 PM Tom Lane wrote:
> Andres Freund writes:
> > On 2018-08-28 13:50:43 +1200, Thomas Munro wrote:
> >> What bad thing would happen if we used OIDs directly as hash values in
> >> internal hash tables (that is, instead of uint32_hash() we'd use
> >> uint32_identity(),
Andres Freund writes:
> On 2018-08-28 13:50:43 +1200, Thomas Munro wrote:
>> What bad thing would happen if we used OIDs directly as hash values in
>> internal hash tables (that is, instead of uint32_hash() we'd use
>> uint32_identity(), or somehow optimise it away entirely, as you can
>> see in
On 2018-08-28 13:50:43 +1200, Thomas Munro wrote:
> I'm curious about something which may qualify as a stupid question.
>
> What bad thing would happen if we used OIDs directly as hash values in
> internal hash tables (that is, instead of uint32_hash() we'd use
> uint32_identity(), or somehow
Hello,
I'm curious about something which may qualify as a stupid question.
What bad thing would happen if we used OIDs directly as hash values in
internal hash tables (that is, instead of uint32_hash() we'd use
uint32_identity(), or somehow optimise it away entirely, as you can
see in some C++
12 matches
Mail list logo
