chiru r wrote:
> I have observed one of our PostgreSQL DB instance showing two postgres
> process on Linux server as highlighted. The second postgres process is on and
> off.
> We did not find any references in logs.
>
> Please provide your advice and help on this issue.
>
> DB version : Postg
On Tue, Aug 20, 2019 at 6:33 AM Karl Martin Skoldebrand
mailto:ks0c77...@techmahindra.com>> wrote:
Hi,
I just discovered that a client has done this:
They have two web applications A1 and A2. They have seperate hostnames/URLs.
Both have a production and a test database A1p and A1t/ A2p and A
Från: Peter J. Holzer
Skickat: den 20 augusti 2019 22:58
Till: pgsql-general@lists.postgresql.org
Ämne: Re: Databases and servers
On 2019-08-20 10:33:17 +, Karl Martin Skoldebrand wrote:
> I just discovered that a client has done this:
>
> They have tw
Pablo:
On Tue, Aug 20, 2019 at 6:49 PM pabloa98 wrote:
> Thank you for your responses Rob. Appreciated. The problem with recursive
> queries is that they are executed several times and it has and impact in
> performance.
> I need a subset of those rows and I want them in one pass.
> I discovere
On Tue, Aug 20, 2019 at 2:46 AM Tom Lane wrote:
>
> "Johann 'Myrkraverk' Oskarsson" writes:
> > On Tue, Aug 20, 2019 at 1:32 AM Tom Lane wrote:
> >> You could manually update the pg_type row, and then if you were
> >> being fussy, add pg_depend entries showing the type depends on
> >> the functi
"Johann 'Myrkraverk' Oskarsson" writes:
> The steps I took are
> create function sha1_send( sha1 ) returns bytea immutable
> language c strict as 'hashtypes', 'sha_send1';
> update pg_type set typsend = 'sha1_send'::regproc
> where typname = 'sha1';
> create function sha1_recv( intern
I agree the function could be improved to deal with both old and new name
existing simultaneously.
That is almost certainly the root cause, and one that I would confirm if the
tester and site were currently available to me.
Our work flow for this scenario is something like:
1. 9.6 pg_dump
On 8/21/19 7:52 AM, Day, David wrote:
I agree the function could be improved to deal with both old and new name
existing simultaneously.
That is almost certainly the root cause, and one that I would confirm if the
tester and site were currently available to me.
Our work flow for this scenari
Hi all,
I have a database query where I have a number of "simple" where clauses, a
number of "complex" subquery based where clauses, and one NOT EXISTS where
clause; it looks something like this:
SELECT ...some fields... FROM Table1
WHERE
Field1 IN (1, 2, 3, 4, 21, 24) AND -- simple filter
> On Aug 21, 2019, at 3:35 AM, Francisco Olarte wrote:
>
> Pablo:
>
> On Tue, Aug 20, 2019 at 6:49 PM pabloa98 wrote:
>> Thank you for your responses Rob. Appreciated. The problem with recursive
>> queries is that they are executed several times and it has and impact in
>> performance.
>> I
If those conditions that are throwing off the stats are expected to be
minimally impactful/filtering few rows, then you can use the one
tried-and-true optimizer hint (aside from materialized CTEs, stylized
indexes, etc) --- OFFSET 0 at the end of a sub-query.
SELECT * FROM ( [your existing query w
Restoring into 11.3 instance the 9.6 dump ? -> yes.
For the upgrade scenario, I confirmed that both old column name and new name
are in the pg_attribute table at the time the patch attempts to rename it.
Why both is a big question.
However,
It is easy enough to re-write the column rename func
I have a situation where we need to import data, as an interim measure,
from spreadsheets.
I have read up on \copy and COPY, but I do not see that either of these can
use the header from a CSV file to define a new table. Am I missing
something?
Also downloaded something called pgfutter, which I
On Wed, Aug 21, 2019 at 2:15 PM stan wrote:
> I have a situation where we need to import data, as an interim measure,
> from spreadsheets.
>
> I have read up on \copy and COPY, but I do not see that either of these can
> use the header from a CSV file to define a new table. Am I missing
> somethi
Thanks Michael.
I'll give some join alternatives a shot first... but, that's cool.
What about OFFSET 0 makes this approach work? I'm thinking the OFFSET 0
create an optimization barrier that prevents the planner from collapsing
that sub-query into the top query, and enforces ordering in the quer
Hi Stan,
I uploaded to the database (PostgreSQL 9.6), monthly and for several
years, over 50 000 000 csv records
using a version of pgtfutter that I compiled (with some changes if I
remember correctly) and the tables
were created in loading process from the column titles.
Dias Costa
On 21
On 8/21/19 4:15 PM, stan wrote:
I have a situation where we need to import data, as an interim measure,
from spreadsheets.
I have read up on \copy and COPY, but I do not see that either of these can
use the header from a CSV file to define a new table. Am I missing
something?
Data types. Sure
On Wednesday, August 21, 2019, Ron wrote:
> On 8/21/19 4:15 PM, stan wrote:
>
>> I have a situation where we need to import data, as an interim measure,
>> from spreadsheets.
>>
>> I have read up on \copy and COPY, but I do not see that either of these
>> can
>> use the header from a CSV file to
On 8/21/19 11:58 AM, Day, David wrote:
Restoring into 11.3 instance the 9.6 dump ? -> yes.
For the upgrade scenario, I confirmed that both old column name and new name
are in the pg_attribute table at the time the patch attempts to rename it.
Why both is a big question.
I been playing aro
-- I'm thinking the OFFSET 0 create an optimization barrier that prevents
the planner from collapsing that sub-query into the top query, and enforces
ordering in the query?
That's my understanding. I think it is an optimizer hint by another name. I
used to put things in a CTE (which is always mate
20 matches
Mail list logo
