Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1taOcS-001UWJ-MU for pgsql-general@arkaria.postgresql.org; Wed, 22 Jan 2025 00:29:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1taOcR-008O14-Bh for pgsql-general@arkaria.postgresql.org; Wed, 22 Jan 2025 00:29:19 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1taOcQ-008O0S-9K for pgsql-general@lists.postgresql.org; Wed, 22 Jan 2025 00:29:19 +0000 Received: from fout-b8-smtp.messagingengine.com ([202.12.124.151]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1taOcN-000odr-1V for pgsql-general@postgresql.org; Wed, 22 Jan 2025 00:29:17 +0000 Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfout.stl.internal (Postfix) with ESMTP id 497FE1140223; Tue, 21 Jan 2025 19:29:15 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Tue, 21 Jan 2025 19:29:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1737505755; x=1737592155; bh=cS81/6XGbczbZgJGBfo9FNQA9RJcgUTqjQUVV0j1AxU=; b= R1/qIkda0qXUItEQUoHMtSuS4V20REL2qI4cKLSce0u38eDNfNmS/TJgrAuZb1tc XW3Ifq0tWmL3/OTBZe75lTrWVOFai2vDaeWQP359Xr2/O5Rf5vs9jhY35rrFvx3i 9lGfQhy7xX45es9KT/wdOwh7X2Iag6PSILJwvJsDVcAtAcQHsQ0UzQyIrgMO9a8S zHUaacbfI+8XUf/X5QDC/r2Mq8iTaWOCJGZC9uG1u6XqNSUX3u0Nfr+p0Ixpe4cA s20FJrXiKV7WCUgodezwiNi55yHFj1So0wj0TEOEUufbwgFeN+TiVULWT7+jZ+qR Ub9y4a+QcTwo+68WdCjcPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1737505755; x=1737592155; bh=c S81/6XGbczbZgJGBfo9FNQA9RJcgUTqjQUVV0j1AxU=; b=sZpdwkPFMVC4eYSGs ORD43TEWYyIkx1nJB8d5HOnp0iEFvgU1CJs29NrWe247zgqtoXkCWLE3IfYn8Ue5 Z4QtuZRi9NlQo3V6uwoyarBwpz3iOiwbmKIaOCHUR3Uaiae3ftPhfhycNl0Rek7S UfuFr6j+usM3t8TBj3ea/sgyp6OFptArkxYecGckNfLY+vnzPZ0HiYP5oNrvI/8Y RXCsGozZTcjwvsSFRaarwyr2WqJPjfDicHAIr344kIGydzaK99+Ba4JQsDRcULBQ QDZ5kRyFWCuNai4SYI0peAjQuBwEbD+M4m/Wew1fWoaaKW7cw9+rbc6AUizcBY3H K1FBw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudejfedgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffvfhfhjggtgfesthekredttddvjeen ucfhrhhomheptegurhhirghnucfmlhgrvhgvrhcuoegrughrihgrnhdrkhhlrghvvghrse grkhhlrghvvghrrdgtohhmqeenucggtffrrghtthgvrhhnpeffleegieefgfevudehtdfh keeutdffjeevgeffgeejvedthefgudeiteefheejheenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrughrihgrnhdrkhhlrghvvghrsegrkhhl rghvvghrrdgtohhmpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprh gtphhtthhopehptghrvghsoheshigrhhhoohdrtghomhdprhgtphhtthhopehpghhsqhhl qdhgvghnvghrrghlsehpohhsthhgrhgvshhqlhdrohhrgh X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 21 Jan 2025 19:29:14 -0500 (EST) Message-ID: <0acacffd-8139-48f8-8b19-6d8e5459f47a@aklaver.com> Date: Tue, 21 Jan 2025 16:29:13 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: concatenating hstores in a group by? To: Brent Wood , Pgsql-general General References: <2268303.1737134384@sss.pgh.pa.us> <9d1dfa7a-4d1d-40c2-960e-5d9240217245@aklaver.com> <660172279.2625291.1737482521074@mail.yahoo.com> Content-Language: en-US From: Adrian Klaver In-Reply-To: <660172279.2625291.1737482521074@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 1/21/25 10:02, Brent Wood wrote: > Yes, a Timescale hypertable with 500,000,000 rows of about 15 key/value > pairs per record. > > I'm not sure why there is both a gin & gist index on the hstore, or the > merits of each. Questions: 1) What is the timezone setting for the database? 2) What is the system time zone where the BASH script is run? 3) Are you sure you don't need the duplicate keys? The keys maybe duplicated, but are the values duplicated also? Also could this be simplified to something like?: create table hstore_tbl (id integer, tsz_fld timestamptz, hstore_fld hstore); insert into hstore_tbl values (1, now(), 'a=>1, b=>2'), (2, now() + interval '0.5 sec', 'a=>3, b=>4'), (3, now() + interval '1 sec', 'a=>1, b=>5'), (4, now() + interval '1.5 sec', 'a=>6, b=>7'); select id, date_trunc('second', tsz_fld) AS t_sec, h.key, h.value from hstore_tbl, each(hstore_fld) as h ; id | t_sec | key | value ----+------------------------+-----+------- 1 | 2025-01-21 14:00:27-08 | a | 1 1 | 2025-01-21 14:00:27-08 | b | 2 2 | 2025-01-21 14:00:28-08 | a | 3 2 | 2025-01-21 14:00:28-08 | b | 4 3 | 2025-01-21 14:00:28-08 | a | 1 3 | 2025-01-21 14:00:28-08 | b | 5 4 | 2025-01-21 14:00:29-08 | a | 6 4 | 2025-01-21 14:00:29-08 | b | 7 It would unnest the data. > > > Thanks.... > >  \d t_reading_hstore_sec >                                          Table > "public.t_reading_hstore_sec" >    Column   |            Type             | Collation | Nullable > |                      Default > ------------+-----------------------------+-----------+----------+--------------------------------------------------- >  key        | bigint                      |           | not null | > nextval('t_reading_hstore_sec_key_seq'::regclass) >  timer      | timestamp without time zone |           | not null | >  values_sec | hstore                      |           |          | > Indexes: >     "t_reading_hstore_sec_pkey" PRIMARY KEY, btree (key, timer) >     "t_reading_hstore_sec_timer_idx" btree (timer) >     "t_reading_hstore_sec_timer_key" UNIQUE CONSTRAINT, btree (timer) >     "t_reading_hstore_sec_values_idx_gin" gin (values_sec) >     "t_reading_hstore_sec_values_idx_gist" gist (values_sec) > > > > > On Wednesday, January 22, 2025 at 06:34:38 AM GMT+13, Adrian Klaver > wrote: > > > On 1/19/25 12:09, Brent Wood wrote: > > Thanks for the replies, appreciated... > > > > My current solution is: > > > > /select trip_code,/ > > /            station_no,/ > > /            timer_sec + interval '12 hour' as NZST,/ > > /            timer_sec as utc,/ > > /            hstore_to_json(string_agg(values_sec::text, ', ')::hstore) > > as values_sec/ > > /     from (select '$TRIP' as trip_code,/ > > /                  $STATION as station_no,/ > > /                  date_trunc('second', timer) as timer_sec,/ > > /                  values_sec/ > > /           from t_reading_hstore_sec/ > > /           where timer >= '$ISO_S'::timestamp - interval '12 hour'/ > > /             and timer <= '$ISO_F'::timestamp - interval '12 hour') > as foo/ > > /group by timer_sec, trip_code, station_no;/ > > > > Convert the hstore to text, aggregate the text with string_agg(), > > convert back to hstore (which seems to remove duplicate keys, OK for my > > purpose) > > To be clear values_sec in t_reading_hstore_sec is the hstore field? > > If so what is it's structure? > > > > and group by timer truncated to whole seconds. I also provide UTC & > > local timezone times for each set of readings. It is run in a bash > > script which passes the trip & station values to the query, as well as > > the start/finish times as ISO format strings. > > > > The output is going to a Sqlite3 (Spatialite) database, which does not > > have hstore, or all the hstore functionality that Postgres has, but does > > have a json datatype which is adequate for our purposes, hence the > > hstore_to_json in the query. > > > > > > Thanks again, > > > > Brent Wood > > > > > -- > Adrian Klaver > adrian.klaver@aklaver.com > > > > -- Adrian Klaver adrian.klaver@aklaver.com