Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

> Before I start in to implement a DELETE / AUTOVACUUM / VACUUM approach, to > recycling disk space used for a session management table, I would like to > propose, for consideration by this forum, an idea for a different approach. > > A row in a session management table, represents a significant

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

On Mon, 30 Nov 2015 23:07:36 -0500, "Steve Petrie, P.Eng." wrote: >Instead of using a DELETE command to destroy the row (and a >resource-intensive AUTOVACUUM / VACUUM process to reclaim the storage >space), why not instead, simply mark that session management row as "free"

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

Thanks to George and Adrian for their latest responses regarding a DELETE / AUTOVACUUM / VACUUM approach, to recycling disk space allocated for rows in a postgres table, that is used to manage sessions (e.g. HTTP sessions with visitor web browsers). My comments are below. In them, I propose an

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

On Sun, 29 Nov 2015 05:04:42 -0500, "Steve Petrie, P.Eng." wrote: >"George Neuner" wrote in message >news:kaed5btl92qr4v8ndevlgtv0f28qaae...@4ax.com... > >> My vote for an email client would be Thunderbird. It runs on XP or >> higher and you can

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

On Nov 29, 2015 18:34, "George Neuner" wrote: > > On Sun, 29 Nov 2015 05:04:42 -0500, "Steve Petrie, P.Eng." > wrote: > > >"George Neuner" wrote in message > >news:kaed5btl92qr4v8ndevlgtv0f28qaae...@4ax.com... > > > >> My vote

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

On 11/29/2015 02:04 AM, Steve Petrie, P.Eng. wrote: Thanks to George for the Thuderbird email client recommendation. My remarks are below. "George Neuner" wrote in message news:kaed5btl92qr4v8ndevlgtv0f28qaae...@4ax.com... On Wed, 25 Nov 2015 23:39:39 -0500, "Steve

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

uot; <timuc...@gmail.com>; "Merlin Moncure" <mmonc...@gmail.com>; "John R Pierce" <pie...@hogranch.com>; "PostgreSQL General" <pgsql-general@postgresql.org> Sent: Thursday, November 26, 2015 2:07 AM Subject: Re: [GENERAL] using a postgres table as a

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

n Moncure" <mmonc...@gmail.com>; "John R Pierce" <pie...@hogranch.com>; "PostgreSQL General" <pgsql-general@postgresql.org> Sent: Thursday, November 26, 2015 2:07 AM Subject: Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue On Wed, No

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

Thanks to George for the helpful comments. My remarks are below. "George Neuner" wrote in message news:gvad5bllba9slstdhkn6ql2jbplgd78...@4ax.com... On Wed, 25 Nov 2015 23:39:39 -0500, "Steve Petrie, P.Eng." wrote: My plan was always, to

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

Thanks to George for the Thuderbird email client recommendation. My remarks are below. "George Neuner" wrote in message news:kaed5btl92qr4v8ndevlgtv0f28qaae...@4ax.com... On Wed, 25 Nov 2015 23:39:39 -0500, "Steve Petrie, P.Eng." wrote: My stupid

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

On Sun, 29 Nov 2015 05:02:58 -0500, "Steve Petrie, P.Eng." wrote: >I should have clarified, that I use the the term "fuzzy" to refer to the >probability mechanism, that hooks a small burst of session row deletion >activity, to each one of a randomly-selected portion

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

On Mon, Nov 23, 2015 at 2:41 AM, Chris Withers wrote: > Hi All, > > I wondered if any of you could recommend best practices for using a postgres > table as a queue. Roughly speaking, 100-200 workers will vomit rows and > rates of a few hundres per second into the table

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

I'll add my two cents. I set up something similar a while ago. Here are my suggestions for what they are worth. You don't ever want to delete from such a table so you need to set up something which allows you to truncate the tables when you no longer need them. One way to accomplish this is

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

On Wed, 25 Nov 2015 23:39:39 -0500, "Steve Petrie, P.Eng." wrote: >Now, I'm reading in this forum that in fact, postgres does not efficiently >automatically recycle storage space released by row DELETion. Yes and no. Space resulting from deleted rows is not given back

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

On Wed, Nov 25, 2015 at 8:39 PM, Steve Petrie, P.Eng. wrote: > >> You don't ever want to delete from such a table so you need to set up >> something which allows you to truncate the tables when you no longer need >> them. > > I am migrating a web PHP application (called

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

On Wed, 25 Nov 2015 23:39:39 -0500, "Steve Petrie, P.Eng." wrote: >My stupid email client software (Microsoft Outlook Express on Win XP) >refuses to respect its own "Reply" option settings for inline reply text. >I've been looking for a replacement email client but so far

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

QL General Sent: Wednesday, November 25, 2015 3:50 PM Subject: Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue I'll add my two cents. I set up something similar a while ago. Here are my suggestions for what they are worth. You don't ever want to dele

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

On 11/23/2015 4:41 AM, Chris Withers wrote: Hi All, I wondered if any of you could recommend best practices for using a postgres table as a queue. Roughly speaking, 100-200 workers will vomit rows and rates of a few hundres per second into the table leaving the status as new and then as many

[GENERAL] using a postgres table as a multi-writer multi-updater queue

Hi All, I wondered if any of you could recommend best practices for using a postgres table as a queue. Roughly speaking, 100-200 workers will vomit rows and rates of a few hundres per second into the table leaving the status as new and then as many workers as needed to keep up with the load

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

Hello. On 23.11.2015 11:41, Chris Withers wrote: > Hi All, > > I wondered if any of you could recommend best practices for using a postgres > table as a queue. Roughly speaking, 100-200 workers will vomit rows and rates > of > a few hundres per second into the table leaving the status as new

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

On Mon, Nov 23, 2015 at 12:54 PM, John R Pierce wrote: > On 11/23/2015 2:41 AM, Chris Withers wrote: >> >> >> If it's totally wrong, how should I be looking to approach the problem? > > depending on where these queue entries are coming from, I'd considering > using a message

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

On 11/23/2015 2:51 PM, Merlin Moncure wrote: On Mon, Nov 23, 2015 at 12:54 PM, John R Pierce wrote: > >depending on where these queue entries are coming from, I'd considering >using a message queueing system like AMS, MQseries, etc, rather than trying >to use a relational

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

On 11/23/2015 2:41 AM, Chris Withers wrote: If it's totally wrong, how should I be looking to approach the problem? depending on where these queue entries are coming from, I'd considering using a message queueing system like AMS, MQseries, etc, rather than trying to use a relational

Re: [GENERAL] using a postgres table as a multi-writer multi-updater queue

On 11/23/15 6:12 AM, Ladislav Lenart wrote: I suggest an excellent read on this topic: http://www.depesz.com/2013/08/30/pick-a-task-to-work-on/ Highly recommended if you haven't read it yet. One thing it doesn't mention that you need to be aware of is the vacuum workload on a queue table.