Arup Rakshit wrote:
> Thanks for the link. I read the documentation you linked, and part of it
> I understood and rest went above my head. Probably I need to read it multiple
> times to understand what is going on. I am learning how indexing works in
> DBMS.
> Mostly I understood Btree so far. I a
Oh, this is a very interesting approach! I didn't realize any UUIDs
could be created in a predictable way. Thank you, this might be what I need.
digimer
On 2018-09-25 1:47 a.m., James Keener wrote:
Also, modified time doesn't need to be the current time, if it starts
as "null" and is set o
Also, modified time doesn't need to be the current time, if it starts as
"null" and is set on the first update, and all subsequent updates, the
pre-update modified time could be used to help key the history pk.
Jim
On Tue, Sep 25, 2018 at 1:45 AM James Keener wrote:
> v3 UUIDs are basically MD5
v3 UUIDs are basically MD5 hashes (v5 is sha1?). So for the same input
you'll always get the same hash.
I had assumed the modified time would be the same; if that's not, then I'm
not sure and my gut tells me this becomes A Really Hard Problem™.
Jim
On Tue, Sep 25, 2018 at 1:38 AM digimer wrote:
On 2018-09-25 1:33 a.m., James Keener wrote:
Do you need a single field for the pk or can you just make it the
(original_table_pk, modified_time)? Alternatively, you could generate
a uuid v3 from the (original_table_pk, modified_time) using something
like uuid_generate_v3(uuid_nil(), original_t
Do you need a single field for the pk or can you just make it the
(original_table_pk, modified_time)? Alternatively, you could generate a
uuid v3 from the (original_table_pk, modified_time) using something like
uuid_generate_v3(uuid_nil(), original_table_pk || ":" || modified_time)?
On 2018-09-25 1:22 a.m., digimer wrote:
Can I tell a produce to use a specific UUID?
s/produce/procedure/
Hi all,
I've got an interesting use case that I am stuck on. It's a bit of a
complicated environment, but I'll try to keep it simple.
In short; I have a history schema that has tables that match the
public schema, plus one 'history_id' column that has a simple sequential
bigserial value.
Hello Thomas,
Thanks for the link. I read the documentation you linked, and part of it I
understood and rest went above my head. Probably I need to read it multiple
times to understand what is going on. I am learning how indexing works in DBMS.
Mostly I understood Btree so far. I am an applicat
Hi
On Mon, 2018-09-24 at 10:46 +0100, Mark Williams wrote:
> Hi thanks,
>
> Sadly PHP and IIS isn't the issue. It’s when you bring Postgres into
> the fold that I am getting a problem. But thanks.
>
> Mark
>
>
I'm not a Windows user and no little about setting up Postgres using
IIS, but you mi
On 9/24/18 2:24 AM, Richard Nielsen wrote:
Hi,
I'm new to PostgresSQL and to this list! I have installed version 10
64-bit (on Windows 7) I also used stackbuilder to install the ODBC
drivers. The SQL shell allows me to logon to the server as postgres but
when starting pgAdmin I get: The appli
Pavan Deolasee wrote:
> On Mon, Sep 24, 2018 at 2:20 PM, Laurenz Albe
> wrote:
> >
> > But how can it be that the first run has to touch 74917 blocks,
> > while whe second run only needs to touch 1185?
> >
>
> The first index scan may have killed lots of index tuples.
So the first index scan
Hi thanks,
Sadly PHP and IIS isn't the issue. It’s when you bring Postgres into the fold
that I am getting a problem. But thanks.
Mark
__
-Original Message-
From: Adrian Klaver
Sent: 23 September 2018 15:36
To: Mark Williams ; pgsql-general@lists.postgresql.org;
dan...@manitou-mail.
Hi,
I'm new to PostgresSQL and to this list! I have installed version 10
64-bit (on Windows 7) I also used stackbuilder to install the ODBC
drivers. The SQL shell allows me to logon to the server as postgres but
when starting pgAdmin I get: The application server could not be
contacted. This
On Mon, Sep 24, 2018 at 2:20 PM, Laurenz Albe
wrote:
>
>
> But how can it be that the first run has to touch 74917 blocks,
> while whe second run only needs to touch 1185?
>
>
The first index scan may have killed lots of index tuples.
Thanks,
Pavan
--
Pavan Deolasee http://w
Last week I encountered the following at a customer site on PostgreSQL 9.6,
and I cannot explain it.
The first run gave me this:
Index Scan using device_outbound_messages_status on device_outbound_messages
(cost=0.43..20.46 rows=97 width=128) (actual time=34.021..35.545 rows=133
loops=1)
I
Thank you all very much for this information
On Sat, Sep 22, 2018 at 12:38 AM Alban Hertroys wrote:
>
>
> > On 21 Sep 2018, at 17:49, Durgamahesh Manne
> wrote:
> >
> >
>
> Considering how hard you try to get rid of duplicates, I'm quite convinced
> that you're at least short a few join condit
17 matches
Mail list logo
