You guys are brilliant!
Regards,
Gus
On Sat, Aug 28, 2021 at 6:26 PM Tom Lane wrote:
> Here is a second patch, quite independent of the first one, that
> gets rid of some other repetitive queries. On the regression database,
> the number of queries needed to do "pg_dump -s regression" drops f
On 2021-Aug-28, Tom Lane wrote:
> Here is a second patch, quite independent of the first one, that
> gets rid of some other repetitive queries.
Another pointlessly repetitive query is in getTriggers, which we run
once per table to be dumped containing triggers. We could reduce that
by running it
Alvaro Herrera writes:
> Another pointlessly repetitive query is in getTriggers, which we run
> once per table to be dumped containing triggers. We could reduce that
> by running it in bulk for many relations at a time. I suppose it's
> normally not hurtful, but as we grow the number of partitio
Readers,
Some advice would be appreciated about appropriate tables to store temporary
data.
Scenario:
User copies csv file of user data, presumably into some temporary table(s);
User selects data (read-only) from extant tables;
Web server combines user data with read-only data to produce content
On 8/29/21 9:10 AM, ourdiaspora wrote:
Readers,
Some advice would be appreciated about appropriate tables to store temporary
data.
Scenario:
User copies csv file of user data, presumably into some temporary table(s);
Presumably not. Temporary tables only live at most for the length of a
ses
On 8/29/21 9:24 AM, Adrian Klaver wrote:
On 8/29/21 9:10 AM, ourdiaspora wrote:
Readers,
User selects data (read-only) from extant tables;
Web server combines user data with read-only data to produce content
visible to user as html and/or pdf document;
User does not need to sign in to use w
‐‐‐ Original Message ‐‐‐
On Sunday, August 29th, 2021 at 5:24 PM, Adrian Klaver
wrote:
>
> Presumably not. Temporary tables only live at most for the length of a
>
> session. It would be a really bad idea to hold sessions open for 24
>
> hours.
Is there an alternative scenario, such as
‐‐‐ Original Message ‐‐‐
On Sunday, August 29th, 2021 at 5:30 PM, Adrian Klaver
wrote:
> On 8/29/21 9:24 AM, Adrian Klaver wrote:
>
>
> Whoops, unfinished thought. What I was going to ask is:
>
> The above is not clear to me. Are you asking about the Postgres
>
> documentation?
>
Yes
On 29/08/2021 17:36, ourdiaspora wrote:
‐‐‐ Original Message ‐‐‐
On Sunday, August 29th, 2021 at 5:24 PM, Adrian Klaver
wrote:
Presumably not. Temporary tables only live at most for the length
of a
session. It would be a really bad idea to hold sessions open for
24
hours.
Is ther
On Sunday, August 29, 2021, ourdiaspora wrote:
>
>
> Yes, wanted to know relevant parts because often the first problem is to
> know which part of the (extensive) documentation to read...
>
>
Suggest you just start developing. When you get stuck the nature of the
block should inform where to go l
On Sunday, August 29, 2021, Ray O'Donnell wrote:
>
>>>
>> Is there an alternative scenario, such as the user is able to create
>> a new table with saves the session data for a maximum time (such as
>> 24 hours), even up to a certain time if the web browser crashes for
>> example?
>
>
In general a
‐‐‐ Original Message ‐‐‐
On Sunday, August 29th, 2021 at 5:38 PM, Ray O'Donnell
wrote:
>
> I'd save a timestamp with the session data, and then run a cron job
>
> which deletes sessions older than whatever lifetime you want.
>
Is it prudent in this scenario for the user to create (a)
On 8/29/21 9:36 AM, ourdiaspora wrote:
‐‐‐ Original Message ‐‐‐
On Sunday, August 29th, 2021 at 5:24 PM, Adrian Klaver
wrote:
Presumably not. Temporary tables only live at most for the length of a
session. It would be a really bad idea to hold sessions open for 24
hours.
Is ther
On 8/29/21 9:38 AM, ourdiaspora wrote:
‐‐‐ Original Message ‐‐‐
On Sunday, August 29th, 2021 at 5:30 PM, Adrian Klaver
wrote:
On 8/29/21 9:24 AM, Adrian Klaver wrote:
Whoops, unfinished thought. What I was going to ask is:
The above is not clear to me. Are you asking about the Po
On 29/08/2021 17:53, Adrian Klaver wrote:
On 8/29/21 9:38 AM, ourdiaspora wrote:
‐‐‐ Original Message ‐‐‐
On Sunday, August 29th, 2021 at 5:30 PM, Adrian Klaver
wrote:
On 8/29/21 9:24 AM, Adrian Klaver wrote:
Whoops, unfinished thought. What I was going to ask is:
The above is
On Sunday, August 29th, 2021 at 5:56 PM, Ray O'Donnell
wrote:
>
- or do they connect only to the web server, which then
>
> uses its own account on the database server?
Thank you; was not aware of this consideration and this option seems most
appropriate for the simple sql commands envisaged.
On 8/29/21 12:24 PM, Adrian Klaver wrote:
Presumably not. Temporary tables only live at most for the length of a
session. It would be a really bad idea to hold sessions open for 24
hours. That is assuming nothing else causes the session to drop and
the data to be lost.
Well, that's precise
On 8/29/21 10:41 AM, Mladen Gogala wrote:
On 8/29/21 12:24 PM, Adrian Klaver wrote:
Presumably not. Temporary tables only live at most for the length of a
session. It would be a really bad idea to hold sessions open for 24
hours. That is assuming nothing else causes the session to drop and
th
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alvaro Herrera writes:
> > Another pointlessly repetitive query is in getTriggers, which we run
> > once per table to be dumped containing triggers. We could reduce that
> > by running it in bulk for many relations at a time. I suppose it's
>
On 8/29/21 2:26 PM, Adrian Klaver wrote:
The pool is maintained, the individual connections(sessions) come and
go. Otherwise there would be no point to having a pool. Every time the
connection(session) is closed the temporary table disappears.
Yes, you're right. And that is very convenient.
20 matches
Mail list logo
