On Mon, 20 Feb 2023 at 13:17, Tom Lane wrote:
> I suspect most of the remaining performance discrepancy is just triggered
> by having to pass the extra always-NULL column forward through the various
> plan steps. We could teach createplan.c to generate a WindowAgg plan node
> that omits the usele
Greetings,
* Tomas Pospisek (t...@sourcepole.ch) wrote:
> so I'm trying to authenticate psql (on Windows) -> postgres (on Linux) via
> Active Directory.
Looks like you're trying to do a bit more than that as you're using
GSSAPI (not SSPI, which would be the more typical method on Windows..)
and y
David Rowley writes:
> On Mon, 20 Feb 2023 at 13:17, Tom Lane wrote:
>> We could teach createplan.c to generate a WindowAgg plan node
>> that omits the useless column from ordNumCols/ordColIdx/etc, but I'm not
>> sure if that'd save much in itself.
> I wonder what the comment had in mind when it
On Sun, Feb 19, 2023 at 4:18 PM Tom Lane wrote:
> Kirk Wolak writes:
> > I have some converted code that uses this syntax.
>
> Seems kinda dumb, but ...
>
> > The solution is to remove the ORDER BY NULL. [since that is not
> > sortable, should it be ignored?]
> > This does NOT SHOW UP wit
Hi,
maybe I am missing something...
with superuser rights, on a postgres 14 and postgres 15 version:
select setting, boot_val, reset_val from pg_settings where
name='log_connections';
off off off
alter system set log_connections to 'on';
select setting, boot_val, reset_val from pg_settings wh
On 2/20/23 08:57, Marc Millas wrote:
select setting, boot_val, reset_val from pg_settings where
name='log_connections';
# select setting, boot_val, reset_val, context from pg_settings where
name='log_connections';
setting | boot_val | reset_val | context
-+--+-
On Mon, Feb 20, 2023 at 9:57 AM Marc Millas wrote:
>
> select pg_reload_conf();
> t
>
> So, I am perplexed: what pg_reload_conf() is doing/not doing ?
>
It is sending a signal and stating success that said signal was sent.
David J.
[Still a newbie; but learning fast...]
Hi,
A remote team member is helping out by dumping some of his tables via
pgAdmin4 on Windows. My DB is on Linux.
The other day, I restored his first file with:
pg_restore --host "localhost" --port "5432" --username "postgres"
--no-password --dbname "m
p...@pfortin.com writes:
> The other day, I restored his first file with:
> pg_restore --host "localhost" --port "5432" --username "postgres"
> --no-password --dbname "myname" --create --clean --verbose "dumpfile"
> Was my 134 table[1] myname DB saved because it was open?
Yup.
> If the dump
On 2/20/23 10:27, p...@pfortin.com wrote:
[Still a newbie; but learning fast...]
Hi,
A remote team member is helping out by dumping some of his tables via
pgAdmin4 on Windows. My DB is on Linux.
The other day, I restored his first file with:
pg_restore --host "localhost" --port "5432" --us
On Mon, 20 Feb 2023 11:06:34 -0800 Adrian Klaver wrote:
>On 2/20/23 10:27, p...@pfortin.com wrote:
>> [Still a newbie; but learning fast...]
>>
>> Hi,
>>
>> A remote team member is helping out by dumping some of his tables via
>> pgAdmin4 on Windows. My DB is on Linux.
>>
>> The other day, I r
I'm concerned that Autovacuum may not be running based on the results of
this query.
SELECT relname, last_vacuum, last_autovacuum FROM pg_stat_user_tables;
gives 211 rows like this...
*relname| last_vacuum |
last_autovacuum*BusinessIncidentCategories
| null | null
Valid Use
> b...@yugabyte.com wrote:
>
> ...it's not clear who actually implements the opening "start transaction"
> and the closing "commit" around every submitted SQL statement when
> autocommit is "on". Is this done in client-side code (maybe implying
> three round trips per in
On 2/20/23 11:36, p...@pfortin.com wrote:
On Mon, 20 Feb 2023 11:06:34 -0800 Adrian Klaver wrote:
On 2/20/23 10:27, p...@pfortin.com wrote:
[Still a newbie; but learning fast...]
Hi,
A remote team member is helping out by dumping some of his tables via
pgAdmin4 on Windows. My DB is on Linux
> On Feb 20, 2023, at 11:57, Bryn Llewellyn wrote:
> 2. If I send over "begin" and then "insert into s.t(v) values(42)", then (so
> far) a second session will not see the effect of my SQL's. It sees this only
> when I send over "commit". (If I send over "rollback" instead of "commit",
> then
On Mon, Feb 20, 2023 at 12:57 PM Bryn Llewellyn wrote:
> 3. Chapter 55 also has a section "Multiple Statements In A Simple Query".
> But this feature seems to do no more semantically beyond implicitly
> achieving what I could do by surrounding several statements explicitly with
> "begin; ... comm
Thanks Adrian,
the fact that the changes are visible only by the new backend, and NOT by
the backend which did the changes was what I did missed.
Marc MILLAS
Senior Architect
+33607850334
www.mokadb.com
On Mon, Feb 20, 2023 at 6:01 PM Adrian Klaver
wrote:
> On 2/20/23 08:57, Marc Millas wrot
> x...@thebuild.com wrote:
>
>> b...@yugabyte.com wrote:
>>
>> 2. If I send over "begin" and then "insert into s.t(v) values(42)", then (so
>> far) a second session will not see the effect of my SQL's. It sees this only
>> when I send over "commit". (If I send over "rollback" instead of "commit
Bryn Llewellyn wrote:
> 2023-02-20 12:42:44.993 PST [2540504] d0$u0@d0 LOG: 0: statement:
> insert into s.t(v) values(17); insert into s.t(v) values(42);
> 2023-02-20 12:42:44.993 PST [2540504] d0$u0@d0 LOCATION: exec_simple_query,
> postgres.c:971
>
> It seems a bit odd that psql h
On 2/20/23 11:36, p...@pfortin.com wrote:
On Mon, 20 Feb 2023 11:06:34 -0800 Adrian Klaver wrote:
On 2/20/23 10:27, p...@pfortin.com wrote:
[Still a newbie; but learning fast...]
Hi,
Notwithstanding the man page, my take is that the DROP DATABASE statement
needs to be eliminated at pg_dum
>> b...@yugabyte.com wrote:
>>
>> It seems a bit odd that psql has no syntax to ask for this in its
>> interactive mode.
>
> dan...@manitou-mail.org wrote:
>
> Backslash-semicolon is the syntax.
Thanks, Daniel. Yes, that works. And the server’s SQL statement log confirms
this.
I’ve no idea
> On Feb 20, 2023, at 17:54, Bryn Llewellyn wrote:
>
>
> I’ve no idea how I might have found this without human help.
That sounds like an excellent documentation patch!
>> b...@yugabyte.com wrote:
>>
>> I’ve no idea how I might have found this without human help.
>
> x...@thebuild.com wrote:
>
> That sounds like an excellent documentation patch!
Well, it’s already documented clearly enough. The question is how to find
it—especially if you don’t know that the
On Mon, 20 Feb 2023 15:24:23 -0800 Adrian Klaver wrote:
>On 2/20/23 11:36, p...@pfortin.com wrote:
>> On Mon, 20 Feb 2023 11:06:34 -0800 Adrian Klaver wrote:
>>
>>> On 2/20/23 10:27, p...@pfortin.com wrote:
[Still a newbie; but learning fast...]
Hi,
>
>>
>> Notwithstanding t
On 2/20/23 19:22, p...@pfortin.com wrote:
On Mon, 20 Feb 2023 15:24:23 -0800 Adrian Klaver wrote:
It just dawned on me you might be doing all of this through the
pgAdmin4 GUI.
Sorry for any confusion... I get it now...
A team member uses pgAdmin4 to load separate table(s) into his DB; th
Probably the result of vacuum freeze manual execution will give some more
information:
Table size:
appdbname3=# \dt+ appschemaname.applications
List of relations
Schema | Name | Type | Owner | Size |
Description
---+
On Mon, Feb 20, 2023 at 9:43 PM Mikhail Balayan wrote:
> What catches my eye: scanning indexes smaller than 3.1GB is fast, larger ones
> are slow. For example:
> idx_applications2_policy_id is 3131 MB took just 5 seconds (DETAIL: CPU:
> user: 2.99 s, system: 1.65 s, elapsed: 5.32 s)
> but idx_a
27 matches
Mail list logo
