On Thu, Jun 29, 2023 at 7:42 PM wrote:
> Trying to write a script that will run on Linux, Windows, and Mac.
>
This seems impossible on its face unless you use WSL within the Windows
environment. And if you are doing that, then the pathing would be WSL
pathing, not native Windows.
David J.
Hi,
On Thu, Jun 29, 2023 at 10:42:00PM -0400, p...@pfortin.com wrote:
>
> Windows: %APPDATA%\postgresql\pgpass.conf
>
> On Linux, this works. However, on Windows, psql will not read
> pgpass.conf (tried in just about every location I could think of)
>
> Even: "set PGPASSFILE=" does not work.
>
Hi,
Trying to write a script that will run on Linux, Windows, and Mac.
The "standard" credentials file contains:
hostname:port:database:username:password
in:
Linux: .pgpass
Windows: %APPDATA%\postgresql\pgpass.conf
Mac: (I'm not there yet...)
On Linux, this works. However, on Windows,
Hi,
@Marc, I think there is no problem.Even though it says it is filtered by
ladate, it is not. Because of the partition.
As you can see for each index scan it uses a different partition and those
partition boundaries are already specified logically.
For example; "Parallel Index Scan using table1_
On Thu, Jun 29, 2023 at 7:55 PM Marc Millas wrote:
>
> Hi,
>
> the documentation, on chapter 5.11.3.3 caveat says that a manual vacuum or
> analyze on the root table does it only for that said root table. To my
> understanding, the root table when used with declarative partitioning, does
> not
Hi,
the documentation, on chapter 5.11.3.3 caveat says that a manual vacuum or
analyze on the root table does it only for that said root table. To my
understanding, the root table when used with declarative partitioning, does
not contain data, so vacuuming or analyzing should be 'fast'.
If I run
Le mer. 28 juin 2023 à 22:46, Laurenz Albe a
écrit :
> On Wed, 2023-06-28 at 19:25 +0200, Marc Millas wrote:
> > Hi Laurenz, as said, in each partition there is only one value for
> ladate.
>
> The planner doesn't seem to take that into account.
>
Indeed. I did check values in pg_statistic. And r
Assuming a particular schema is standalone, i.e. does not depend
on any other external schema, I'd like to know the order in which to
(re)populate tables from data coming from (an existing) custom storage.
When the schema's table have foreign key relationships,
"parent" tables must be populated be
On Wed, Jun 28, 2023 at 1:22 PM Tom Lane wrote:
> I wrote:
> > That number is the total space actually requested from malloc() for
> > the PGresult object. But we request space in blocks (typically 2KB
> > each), so there's some overhead due to fields not exactly filling
> > a block, unused spac
