Greetings,
* Peter J. Holzer (hjp-pg...@hjp.at) wrote:
> On 2019-05-18 19:16:19 -0500, Ron wrote:
> > > If the the table fills up, you increase nr_buckets, reallocate and
> > > rehash all entries.
> >
> > Ouch. Response time on a big table would take a serious hit if that rehash
> > happened in
Greetings,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Thu, May 16, 2019 at 8:31 AM Daulat Ram
> wrote:
>
> > url_hash| bigint | | not null |
>
> Change the type of url_hash; make it text instead of bigint.
Making it text wastes a bunch of sp
On 5/19/19 5:43 AM, Peter J. Holzer wrote:
[snip]
But please be aware that I answered your question 'How is it "using
math" to use a hash key?', not 'How are hash indexes in PostgreSQL
implemented?'. So my answer covered the most simple and generic
implementation.
I understand.
--
Angular mome
On 2019-05-18 19:16:19 -0500, Ron wrote:
> On 5/18/19 5:39 PM, Peter J. Holzer wrote:
> > On 2019-05-18 17:14:59 -0500, Ron wrote:
> > > On 5/18/19 3:49 PM, Peter J. Holzer wrote:
> > > On 2019-05-18 15:19:22 -0500, Ron wrote:
> > > On 5/18/19 2:27 PM, Peter J. Holzer wrote:
> > >
On 5/18/19 5:39 PM, Peter J. Holzer wrote:
On 2019-05-18 17:14:59 -0500, Ron wrote:
On 5/18/19 3:49 PM, Peter J. Holzer wrote:
On 2019-05-18 15:19:22 -0500, Ron wrote:
On 5/18/19 2:27 PM, Peter J. Holzer wrote:
On 2019-05-18 10:49:53 -0700, David G. Johnston wrote:
On 2019-05-18 17:14:59 -0500, Ron wrote:
> On 5/18/19 3:49 PM, Peter J. Holzer wrote:
>
> On 2019-05-18 15:19:22 -0500, Ron wrote:
>
> On 5/18/19 2:27 PM, Peter J. Holzer wrote:
>
> On 2019-05-18 10:49:53 -0700, David G. Johnston wrote:
>
> You don’t perf
On 5/18/19 3:49 PM, Peter J. Holzer wrote:
On 2019-05-18 15:19:22 -0500, Ron wrote:
On 5/18/19 2:27 PM, Peter J. Holzer wrote:
On 2019-05-18 10:49:53 -0700, David G. Johnston wrote:
You don’t perform math on a hash
That's not generally true. Hashes are used for further computation for
example
On 2019-05-18 15:19:22 -0500, Ron wrote:
> On 5/18/19 2:27 PM, Peter J. Holzer wrote:
> > On 2019-05-18 10:49:53 -0700, David G. Johnston wrote:
> > > You don’t perform math on a hash
> > That's not generally true. Hashes are used for further computation for
> > example in hash tables or in cryptog
On 5/18/19 2:27 PM, Peter J. Holzer wrote:
On 2019-05-18 10:49:53 -0700, David G. Johnston wrote:
On Saturday, May 18, 2019, Peter J. Holzer wrote:
On 2019-05-16 08:48:51 -0700, David G. Johnston wrote:
> On Thu, May 16, 2019 at 8:31 AM Daulat Ram
wrote:
>
>
>
On 2019-05-18 10:49:53 -0700, David G. Johnston wrote:
> On Saturday, May 18, 2019, Peter J. Holzer wrote:
>
> On 2019-05-16 08:48:51 -0700, David G. Johnston wrote:
> > On Thu, May 16, 2019 at 8:31 AM Daulat Ram
> wrote:
> >
> >
> > url_hash | bigint
On Saturday, May 18, 2019, Peter J. Holzer wrote:
> On 2019-05-16 08:48:51 -0700, David G. Johnston wrote:
> > On Thu, May 16, 2019 at 8:31 AM Daulat Ram
> wrote:
> >
> >
> > url_hash| bigint | | not null |
> >
> >
> > Change the type of url_hash; make it t
On 2019-05-16 08:48:51 -0700, David G. Johnston wrote:
> On Thu, May 16, 2019 at 8:31 AM Daulat Ram wrote:
>
>
> url_hash | bigint | | not null |
>
>
> Change the type of url_hash; make it text instead of bigint.
Or numeric(38, 0). I think it isn't coinci
Adding to what David said, I don't see much point of having a bigint
status. Usually status attributes are a fixed set of values that can be
checked programmatically.
>
On Thu, May 16, 2019 at 8:31 AM Daulat Ram
wrote:
> url_hash| bigint | | not null |
>
Change the type of url_hash; make it text instead of bigint.
As a bonus:
Use text instead of arbitrary varchar(4000) fields and add, e.g., check
(length(url) < 4000) or some
On Thu, 16 May 2019 at 16:31, Daulat Ram wrote:
> Hello team ,
>
> We are getting ERROR: bigint out of range. Please help on this.
>
>
>
Bigint is -9223372036854775808 to 9223372036854775807.
https://www.postgresql.org/docs/current/datatype-numeric.html
Hello team ,
We are getting ERROR: bigint out of range. Please help on this.
ERROR: bigint out of range
kbdb=# INSERT INTO kb_dar_ran_url_check
(url_hash,stat_date,topic_id,site_id,url,status,user_comments,review_comments)
VALUES
(72894677781133866997924561390146294513,E'19-04
On Sat, Jun 09, 2018 at 07:20:17AM -0700, Adrian Klaver wrote:
> On 06/09/2018 05:24 AM, Alexey Dokuchaev wrote:
> >OK, but what about highly volatile tables for come-and-go type of things?
> >Think of a session pool, or task queue. I want to use NO CYCLE for this
> >kind of tables as it would all
On 06/09/2018 05:24 AM, Alexey Dokuchaev wrote:
On Fri, Jun 08, 2018 at 10:30:45AM -0700, Adrian Klaver wrote:
My guess is because sequences are often used to provide numbers for a
PRIMARY KEY and NO CYCLE is a heads up for key duplication before the
PK code kicks in.
OK, but what about hig
On Fri, Jun 08, 2018 at 10:30:45AM -0700, Adrian Klaver wrote:
> On 06/08/2018 10:23 AM, Alexey Dokuchaev wrote:
> >I've decided to run some tests to see how my tables' ids would survive
> >when their yielding sequences would start hitting their MAXVALUE's, by
> >doing some "SELECT setval('foo_id_s
Alexey Dokuchaev writes:
> What is the rationale for (int ^ int) to return double precision rather
> than numeric? I am missing something obvious here?
There are two ^ operators, one taking float8 and one taking numeric.
Since float8 is the preferred datatype in the numeric category
(i.e. the to
On 06/08/2018 10:23 AM, Alexey Dokuchaev wrote:
Hi there,
P.S. On a tangentally related note, why is "NO CYCLE" is the default
for sequences?
[*] Per documentation, "The [SQL] standard's AS expression
is not supported." Another "why is it so?" question, btw. ;-)
I found it. Its in the
---+-+---
integer | 1 | 1 | 2147483647 | 1 | no | 1
Owned by: public.serial_test2.id
avail, in contrast to (2^31 - 1)::int (-> below is short mnemonic for
"returns"):
select (2^31 - 1)::int -> 2147483647 (co
ge numbers, because sequences are always[*]
bigint's), I've tried to use (2^63 - 1)::bigint as "maxbigint", to no
avail, in contrast to (2^31 - 1)::int (-> below is short mnemonic for
"returns"):
select (2^31 - 1)::int -> 2147483647 (correct)
23 matches
Mail list logo
