Your explain analyze is showing an example that runs in less than 15ms, and
your logs indicate queries taking 2-3 seconds. I am missing part of the
picture here. Can you clarify?
On Fri, Feb 19, 2021 at 4:21 PM Tom Lane wrote:
>
> Yeah, that would be slightly safer. If the public schema is
> world-writable, though, you're in big trouble anyway ...
>
>
Sorry, you lost me with the last sentence. My scenario is that public
_isn't_ world-writable. But everyone can set thei
Ken Tanzer writes:
> One thing about the search path though, regarding pg_temp. If I add a
> SET search_path = public;
> Do I need instead to specify "public, pg_temp" to prevent it from being
> (silently) at the beginning?
Yeah, that would be slightly safer. If the public schema is
world-writa
On Fri, Feb 19, 2021 at 3:22 PM Tom Lane wrote:
> Ken Tanzer writes:
> > On Thu, Feb 18, 2021 at 8:44 PM Tom Lane wrote:
> >> There was a security change to pg_dump a few years ago to make it
> >> put "set search_path = pg_catalog" into the dump script. This
> >> basically means that any user-
Ken Tanzer writes:
> On Thu, Feb 18, 2021 at 8:44 PM Tom Lane wrote:
>> There was a security change to pg_dump a few years ago to make it
>> put "set search_path = pg_catalog" into the dump script. This
>> basically means that any user-defined function in indexes, check
>> constraints, etc is on
Good evening,
I have a word game which uses PostgreSQL 13.2 and 80% of the code is
written as stored functions in PL/PgSQL or SQL.
Recently I have purchased some traffic and the number of daily games
increased from 100 to 700.
In the PostgreSQL log I have noticed that the duration for 2 particul
On Thu, Feb 18, 2021 at 8:44 PM Tom Lane wrote:
> Ken Tanzer writes:
> > I'm not sure what you mean or are suggesting by that. Is there something
> > I'm supposed to do to set the search path? Is that a known bug in
> > pg_dump? Something else? As mentioned, there is only one schema
>
>
On 2021-02-17 08:45:05 +0100, Laurenz Albe wrote:
> On Tue, 2021-02-16 at 16:11 -0600, Ron wrote:
> > SQL is only intuitive to people who've done programming... :)
>
> SQL is quite counter-intuitive to people who have only done
> procedural programming.
Yes, different paradigm. SQL is more like a
On 2021-02-17 12:22:50 +0300, Mutuku Ndeti wrote:
> I agree with you. Single master, with a standby replica, seems easier to
> manage. Is there a way to automatically promote the standby, when the active
> master fails?
Yes. There are several solutions. We use Patroni, which is simple to set
up an
On 2021-02-15 16:15:44 -0500, Joe Abbate wrote:
> As I understand it, the PG server processes doing a SELECT are spawned as
> children of the Go process,
There's a misconception here: The server processes are children of the
postmaster process, not of the client program (whether it's written in
Go
On 2021-02-15 15:34:30 -0800, Adrian Klaver wrote:
> It probably would not hurt to figure why this seemed to happen with the
> Python -> Go switch. Even if you can get the OOM not to kick in, the fact
> that it was kicking in would indicate you now have memory hungry processes
> that did not exist
> De: "sivapostgres"
> Para: "Benedict Holland"
> Cc: "pgsql-general" , "Thomas Kellerer"
>
> Enviadas: Quarta-feira, 17 de fevereiro de 2021 11:09:38
> Assunto: Re: Slow while inserting and retrieval (compared to SQL Server)
> So far no performance tuning done for sql server. It works fine f
On 2021-02-17 12:54:18 +, sivapostg...@yahoo.com wrote:
> Yes, that's what I feel. With no records in any tables, working from the same
> machine where PG has been installed, with only one user working, inserting few
> records (10 records in total, in all 6 tables) should not take this much
>
On 2021-02-16 19:30:23 +0100, Paul van der Linden wrote:
> I have 2 functions:
>
> CREATE FUNCTION foo(a text, b text, c text) RETURNS text AS
> $func$
> DECLARE
> retVal text;
> BEGIN
> SELECT
> CASE
> ... snip long list containing various tests on a,b and c
> END INTO
On Fri, 2021-02-19 at 11:21 +0100, Luca Ferrari wrote:
> > At execution time, PostgreSQL will use as many of the planned workers
> > as are currently available (max_parallel_workers).
>
> Thanks, but just to make it clear, assuming I execute almost
> simultanously two identical queries that can be
On Fri, Feb 19, 2021 at 10:43 AM Laurenz Albe wrote:
> At execution time, PostgreSQL will use as many of the planned workers
> as are currently available (max_parallel_workers).
Thanks, but just to make it clear, assuming I execute almost
simultanously two identical queries that can be therefore
On Fri, 2021-02-19 at 10:38 +0100, Luca Ferrari wrote:
> I know that parallel processes can be limited by
> max_parallel_workers_per_gather and max_parallel_workers, as well as
> the condition to consider a parallel plan is min_table_scan_size (and
> index). But I would like to understand, once a t
Hi all,
I know that parallel processes can be limited by
max_parallel_workers_per_gather and max_parallel_workers, as well as
the condition to consider a parallel plan is min_table_scan_size (and
index). But I would like to understand, once a table has been
considered for a parallel plan, and there
18 matches
Mail list logo
