> On Mar 1, 2024, at 11:36 AM, normandavis1990
> wrote:
>
> > On Thursday, February 29th, 2024 at 11:38 PM, Israel Brewster
> > wrote:
>>> On Feb 29, 2024, at 10:15 AM, David G. Johnston
>>> wrote:
>>>
>>>
>>>
>>&
over
system or load balancer. Many different options that work in many different
ways are available to help meet this goal.
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907-328-9145
>
> David J.
>
; 10.128.206.0/23 password
>
I might be missing something obvious, but your error says “no encryption”,
while the pg_hba entry is “hostssl” indicating it will match encrypted
connections only, so it doesn’t match.
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Ins
ed that specifically).
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907-328-9145
> Thanks in advance!
>
> Yours,
> Wen Yi.
, based
not on the primary key (which I don’t know for incoming data), but on the
station and timestamp. UPSERT, but not based on the primary key.
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-4
> On Mar 13, 2023, at 12:25 PM, Joe Conway wrote:
>
> On 3/13/23 16:18, Israel Brewster wrote:
>>> Did you try setting "vm.overcommit_memory=2"?
>
>> root@novarupta:~# sysctl -w vm.overcommit_memory=2
>> sysctl: setting key "vm.overcommit_me
> On Mar 13, 2023, at 12:16 PM, Peter J. Holzer wrote:
>
> On 2023-03-13 09:55:50 -0800, Israel Brewster wrote:
>> On Mar 13, 2023, at 9:43 AM, Peter J. Holzer wrote:
> The syslog should contain a list of all tasks prior to the kill. For
> example, I just provoked an OOM
> On Mar 13, 2023, at 11:42 AM, Joe Conway wrote:
>
> On 3/13/23 15:18, Israel Brewster wrote:
>> The syslog specifically says "Memory cgroup out of memory”, if that means
>> something (this is my first exposure to cgroups, if you couldn’t
>> tell).
>
&g
On Mar 13, 2023, at 11:10 AM, Joe Conway wrote:
>
> On 3/13/23 14:50, Israel Brewster wrote:
>> Looks like V2:
>> root@novarupta:~# stat -fc %T /sys/fs/cgroup/
>> cgroup2fs
>
> Interesting -- it does indeed look like you are using cgroup v2
>
> So the file
> On Mar 13, 2023, at 10:37 AM, Joe Conway wrote:
>
> On 3/13/23 13:55, Israel Brewster wrote:
>> 1) They reference a “Memory cgroup out of memory”, which refers back
>> to the opening comment on Joe Conway’s message - this would imply to
>> me that I *AM* running wit
> On Mar 13, 2023, at 9:43 AM, Peter J. Holzer wrote:
>
> On 2023-03-13 09:21:18 -0800, Israel Brewster wrote:
>> I’m running a postgresql 13 database on an Ubuntu 20.04 VM that is a bit more
>> memory constrained than I would like, such that every week or so the various
&g
> On Mar 13, 2023, at 9:36 AM, Joe Conway wrote:
>
> On 3/13/23 13:21, Israel Brewster wrote:
>> I’m running a postgresql 13 database on an Ubuntu 20.04 VM that is a bit
>> more memory constrained than I would like, such that every week or so the
>> various proce
> On Mar 13, 2023, at 9:28 AM, Adrian Klaver wrote:
>
> On 3/13/23 10:21 AM, Israel Brewster wrote:
>> I’m running a postgresql 13 database on an Ubuntu 20.04 VM that is a bit
>> more memory constrained than I would like, such that every week or so the
>> vario
is probably not the greatest idea.
Which makes me wonder what is really going on?
Thanks.
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907-328-9145
talking to the timescaledb people tomorrow)!
Thanks again!
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907-328-9145
> On Oct 4, 2021, at 12:46 PM, Ron wrote:
>
> On 10/4
two column, non-UNIQUE index is preferable), and I ran the query
several times both with and without the station-date index to (hopefully) make
sure there were no caching issues.
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907-328-9145
> On Oct 4, 2021, at 1:21 PM, Rob Sargent wrote:
>
> On 10/4/21 3:09 PM, Israel Brewster wrote:
>>> On Oct 4, 2021, at 12:46 PM, Ron >> <mailto:ronljohnso...@gmail.com>> wrote:
>>>
>>> On 10/4/21 12:36 PM, Israel Brewster wrote:
>
> On Oct 4, 2021, at 12:46 PM, Ron wrote:
>
> On 10/4/21 12:36 PM, Israel Brewster wrote:
> [snip]
>> Indeed. Table per station as opposed to partitioning? The *most* I can
>> reasonably envision needing is to query two stations, i.e. I could see
>> potentially w
> On Oct 4, 2021, at 9:22 AM, Rob Sargent wrote:
>
> On 10/4/21 11:09 AM, Israel Brewster wrote:
>>> On Oct 4, 2021, at 8:46 AM, Rob Sargent >> <mailto:robjsarg...@gmail.com>> wrote:
>>>
>>>> On Oct 4, 2021, at 10:22 AM, Israel Brewster &
> On Oct 4, 2021, at 8:46 AM, Rob Sargent wrote:
>
>> On Oct 4, 2021, at 10:22 AM, Israel Brewster > <mailto:ijbrews...@alaska.edu>> wrote:
> Guessing the “sd” is "standard deviation”? Any chance those stddevs are
> easily calculable from base data? Could c
t; btree (station, channel)
"station_data_idx" btree (station)
"station_date_idx" btree (station, datetime)
Foreign-key constraints:
"data_station_fkey" FOREIGN KEY (station) REFERENCES stations(id)
Triggers:
update_epoch BEFORE INSERT OR UPDATE OF datetime ON
s?
This is my stumbling block to implementing this option as well. That said, with
the lookup table in place, perhaps all the rest of this is a moot point?
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907-328-9145
> On Sep 23, 2021, at 10:36 AM, Geoff Winkless wrote:
>
> On Wed, 22 Sept 2021 at 21:05, Israel Brewster <mailto:ijbrews...@alaska.edu>> wrote:
> I was wondering if there was any way to improve the performance of this query:
>
> SELECT station,array_agg(distinct(chan
> On Sep 23, 2021, at 8:33 AM, Rob Sargent wrote:
>
> On 9/23/21 10:16 AM, Israel Brewster wrote:
>>> On Sep 23, 2021, at 4:34 AM, Ryan Booz >> <mailto:r...@timescale.com>> wrote:
>>>
>>> Heh, I honestly forgot about the recursive CTE. Certain
ns of hits vs only the occasional insert needed).
Thanks again for all the suggestions!
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907-328-9145
>
> On Thu, Sep 23, 2021 at
> On Sep 22, 2021, at 11:04 PM, hubert depesz lubaczewski
> wrote:
>
> On Wed, Sep 22, 2021 at 12:05:22PM -0800, Israel Brewster wrote:
>> I was wondering if there was any way to improve the performance of this
>> query:
>>
>> SELECT station,array_agg(dist
And this is why I love postgresql and this community - when something isn’t
working as well as I would like, there is usually a way to improve it
drastically :-)
Thanks!
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775
3
> 24
>
> or:
> station | channel
> --|---
> 11
> 12
> 2 1
> 22
>
>
>
>
> On Wed, Sep 22, 2021 at 5:53 PM Israel Brewster <mailto:ijbrews...@alaska.edu>> wrote:
>> On Sep 22
g in your message, i.e. some sort of tweak to the query
to get it to use the timescaledb features?
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907-328-9145
>
> On We
upon the query in question took roughly twice as
long. So you are right that installing timescaledb speeds things up, even when
not using any timescaledb specific functions. So that was a good call. Thanks!
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute -
at autovaccum doesn’t
address? Or perhaps my autovaccum settings aren’t kosher - I haven’t adjusted
that portion of the config any.
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907-328-9145
>
> regards, tom lane
> On Sep 22, 2021, at 12:20 PM, David G. Johnston
> wrote:
>
> On Wed, Sep 22, 2021 at 1:05 PM Israel Brewster <mailto:ijbrews...@alaska.edu>> wrote:
> To work around the issue, I created a materialized view that I can update
> periodically, and of course I can quer
his is running PostgreSQL 13, and the index referenced is a two-column index
on data(station, channel)
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907-328-9145
to the new master
Steps 2-4 should happen in quick succession, resulting in only seconds of
downtime. At least, that’s the theory. We’ll see how it goes (or if anyone else
here can offer a better procedure!)
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute -
allowing for zero (or nearly so) downtime
cutover. Which is nice.
Any gotchas I need to be aware of during this initial transfer window, such as
WAL files building up on the source machine?
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk
Source DB is 11.12, destination is 13.4. I’ll look into logical replication -
It sounds like it could be a good option. Thanks!
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907
g
to proxmox monitoring), nor did the RAM usage increase, so I’m not sure where
the data is actually going, which bothers me.
Is there a better way to do this?
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775
> On Apr 11, 2021, at 6:52 AM, Ron wrote:
>
> On 4/11/21 9:12 AM, Israel Brewster wrote:
>>> On Apr 11, 2021, at 1:53 AM, Stephan Knauss >> <mailto:pg...@stephans-server.de>> wrote:
>>>
>>> Hello Felix,
>>>
>>> On 11.04.202
t that
doesn’t mean much to a new user, and certainly doesn’t indicate a lack of
support by PostgreSQL), so it makes total sense that someone would think to ask
here first when experiencing issues.
If you don’t want to offer assistance, that’s fine, but this link most
certainly IS the lin
> On Aug 10, 2020, at 12:06 PM, Peter J. Holzer wrote:
>
> On 2020-08-10 09:10:00 -0800, Israel Brewster wrote:
>> I would point out, however, that using a V1 UUID rather than a V4 can
>> help with this as it is sequential, not random (based on MAC address
>> and t
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907-328-9145
> On Aug 10, 2020, at 8:53 AM, Stephen Frost wrote:
>
> Greeitngs,
>
> * Ron (ronljohnso...@gmail.co
On May 21, 2020, at 12:12 PM, Sándor Daku wrote:
> Hi,
>
> On Thu, 21 May 2020 at 18:14, Christopher Browne <mailto:cbbro...@gmail.com>> wrote:
> On Thu, 21 May 2020 at 11:53, Israel Brewster <mailto:isr...@brewstersoft.com>> wrote:
>>
>
> - Ta
> On May 21, 2020, at 7:57 AM, Adrian Klaver wrote:
>
> On 5/21/20 8:53 AM, Israel Brewster wrote:
>>> On May 21, 2020, at 7:36 AM, Adrian Klaver >> <mailto:adrian.kla...@aklaver.com>> wrote:
>>>
>>> On 5/21/20 8:29 AM, Israel Brewster wrote
> On May 21, 2020, at 7:36 AM, Adrian Klaver wrote:
>
> On 5/21/20 8:29 AM, Israel Brewster wrote:
>> I’m working on my first cloud service, which will be backed by a postgresql
>> database. Currently I only have a single customer, but of course I want to
>> des
forts, as if I needed to add a field I
would have to add it to every table. On the other hand, keeping everything in
the same set of tables would mean having to be VERY careful with my SQL to make
sure no customer could access another’s data.
How is this typically done?
---
Israel Brewster
Brewste
>
> On Jan 13, 2020, at 3:46 PM, Rob Sargent wrote:
>
>
>
>> On Jan 13, 2020, at 5:41 PM, Israel Brewster > <mailto:ijbrews...@alaska.edu>> wrote:
>>
>>> On Jan 13, 2020, at 3:19 PM, Tom Lane >> <mailto:t...@sss.pgh.pa.us>&g
> On Jan 13, 2020, at 6:34 PM, Dilip Kumar wrote:
>
> On Tue, Jan 14, 2020 at 5:29 AM Israel Brewster <mailto:ijbrews...@alaska.edu>> wrote:
>>
>> I was working on diagnosing a “slow” (about 6 second run time) query:
>>
>> SELECT
>>
> On Jan 13, 2020, at 3:19 PM, Tom Lane wrote:
>
> Israel Brewster writes:
>> In looking at the explain analyze output, I noticed that it had an “external
>> merge Disk” sort going on, accounting for about 1 second of the runtime
>> (explain analyze output here: h
PostgreSQL 11.6 on a machine with 128GB of ram (so, like I said,
plenty of RAM)
How can I fix this? Thanks.
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907-328-9145
> On Jan 8, 2020, at 7:52 AM, stan wrote:
>
> On Tue, Jan 07, 2020 at 12:20:12PM -0900, Israel Brewster wrote:
>>> On Jan 7, 2020, at 12:15 PM, Alan Hodgson wrote:
>>>
>>> On Tue, 2020-01-07 at 11:58 -0900, Israel Brewster wrote:
>>>>>
>&g
>
> On Jan 7, 2020, at 12:57 PM, Adrian Klaver wrote:
>
> On 1/7/20 1:43 PM, Israel Brewster wrote:
>>> On Jan 7, 2020, at 12:21 PM, Adrian Klaver >> <mailto:adrian.kla...@aklaver.com>> wrote:
>>>
>>> On 1/7/20 1:10 PM, Israel Brewster w
> On Jan 7, 2020, at 12:21 PM, Adrian Klaver wrote:
>
> On 1/7/20 1:10 PM, Israel Brewster wrote:
>>> On Jan 7, 2020, at 12:01 PM, Adrian Klaver
>>> wrote:
>>>
>>> On 1/7/20 12:47 PM, Israel Brewster wrote:
>>>> One potential iss
> On Jan 7, 2020, at 12:15 PM, Alan Hodgson wrote:
>
> On Tue, 2020-01-07 at 11:58 -0900, Israel Brewster wrote:
>>>
>> Really? Why? With the update I am only changing data - I’m not adding
>> any additional data, so the total size should stay the same, right?
>
> On Jan 7, 2020, at 12:01 PM, Adrian Klaver wrote:
>
> On 1/7/20 12:47 PM, Israel Brewster wrote:
>> One potential issue I just thought of with this approach: disk space. Will I
>> be doubling the amount of space used while both tables exist? If so, that
>> woul
> On Jan 7, 2020, at 11:56 AM, Alan Hodgson wrote:
>
> On Tue, 2020-01-07 at 11:47 -0900, Israel Brewster wrote:
>> One potential issue I just thought of with this approach: disk space.
>> Will I be doubling the amount of space used while both tables exist?
>> If so, t
One potential issue I just thought of with this approach: disk space. Will I be
doubling the amount of space used while both tables exist? If so, that would
prevent this from working - I don’t have that much space available at the
moment.
---
Israel Brewster
Software Engineer
Alaska Volcano
. Thanks!
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907-328-9145
> On Jan 7, 2020, at 10:09 AM, Mark Zellers wrote:
>
> You don’t tell us if other users will be con
and have to start over from the top. Running in parallel simply seemed to be a
no-brainer option to make it go quicker, assuming CPU bound updating.
Optimizations that are going to take work are probably not worth it. We can
wait for the data to be updated.
Thanks again!
---
Israel Brews
unction, and
the fact that it is currently called via a trigger rather than direct is of
little consequence, but I’m willing to be corrected on that :-)
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907-328-9145
e a better feel for where the
bottlenecks may be, and how long the entire update process would take. I’m
assuming, of course, that the total time would scale more or less linearly with
the number of records.
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - U
> On Jan 6, 2020, at 11:38 AM, Christopher Browne wrote:
>
>
>
> On Mon, Jan 6, 2020, 3:15 PM Israel Brewster <mailto:ijbrews...@alaska.edu>> wrote:
>> On Jan 6, 2020, at 10:08 AM, Christopher Browne > <mailto:cbbro...@gmail.com>> wrote:
>>
> On Jan 6, 2020, at 10:08 AM, Christopher Browne wrote:
>
> On Mon, 6 Jan 2020 at 13:36, Israel Brewster <mailto:ijbrews...@alaska.edu>> wrote:
> Thanks to a change in historical data, I have a need to update a large number
> of records (around 50 million). The u
? Still, there is a good chance you are
correct in that statement, so that aspect is probably not worth spending too
much time on.
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907
ons I
can apply), I’m just wondering if there is a more automatic option.
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907-328-9145
psql is the client, not the server. What user you run psql as doesn’t make a
difference, it’s what user the server is running as that makes the difference,
since it is the server that interacts with the file system. psql simply
connects to and interacts with the PostgreSQL server.
---
Israel
outh and East/West distances, rather than the actual
total “point a to point b” distance. Perhaps there is a better way of obtaining
that goal?
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory
Geophysical Institute - UAF
2156 Koyukuk Drive
Fairbanks AK 99775-7320
Work: 907-474-5172
cell: 907-328-9145
66 matches
Mail list logo
