On Tue, Aug 6, 2019 at 7:57 AM Adrian Klaver
wrote:
> On 8/5/19 7:04 PM, Murtuza Zabuawala wrote:
> > No, pgAdmin4 only supports PostgreSQL 9.2 and later versions.
>
> Where is that mentioned in the documentation?
>
It is mentioned on the front page of https://www.pgadmin.org/
(Check introductio
On 8/5/19 7:04 PM, Murtuza Zabuawala wrote:
No, pgAdmin4 only supports PostgreSQL 9.2 and later versions.
Where is that mentioned in the documentation?
On Tue, 6 Aug 2019, 01:45 Benedict Holland,
mailto:benedict.m.holl...@gmail.com>> wrote:
The subject says it all. I am using a very o
No, pgAdmin4 only supports PostgreSQL 9.2 and later versions.
On Tue, 6 Aug 2019, 01:45 Benedict Holland,
wrote:
> The subject says it all. I am using a very old database that I cant
> upgrade. Do I have to manage it with pgadmin3 or can I use postgresql 4?
>
> Thanks,
> ~Ben
>
>What I really dont want is some strange
> feature that is unique to 8.4 not have support.
Actually, the reverse is more likely. Newer versions of PostgreSQL have
newer and additional
features, so it is highly unlikely that PgAdmin4 would not be able to
support all features in 8.4.
That being sa
On 8/5/19 1:51 PM, Benedict Holland wrote:
Yea. I did look in the doc's. What I really dont want is some strange
feature that is unique to 8.4 not have support. Like, a select option
for example. I am fairly sure most of it will work but my "not
supported" does it mean that it wasnt tested but
Thanks a lot! Very helpful
Sent from my iPhone
> On Aug 5, 2019, at 1:50 PM, Alban Hertroys wrote:
>
>
>> On 5 Aug 2019, at 17:27, Julie Nishimura wrote:
>>
>> Thanks for your reply Alban. Currently we only have A->B replication. Is
>> adding B->C replication difficult? I remember in the pa
Yea. I did look in the doc's. What I really dont want is some strange
feature that is unique to 8.4 not have support. Like, a select option for
example. I am fairly sure most of it will work but my "not supported" does
it mean that it wasnt tested but will probably work or that it really isnt
suppo
> On 5 Aug 2019, at 17:27, Julie Nishimura wrote:
>
> Thanks for your reply Alban. Currently we only have A->B replication. Is
> adding B->C replication difficult? I remember in the past I tried to seed
> pg_basebackup from hot standby, and it was erroring out after awhile, so
> needed to sw
On 8/5/19 1:15 PM, Benedict Holland wrote:
The subject says it all. I am using a very old database that I cant
upgrade. Do I have to manage it with pgadmin3 or can I use postgresql 4?
Trolling the docs does not offer any insight. If you have pgAdmin4
already installed I would just set up a con
The subject says it all. I am using a very old database that I cant
upgrade. Do I have to manage it with pgadmin3 or can I use postgresql 4?
Thanks,
~Ben
George Woodring writes:
> We have been using the model of updating certain data in a table of
> begin;
> delete from foo where bar='myfoo';
> insert into foo all of the correct data for myfoo;
> commit;
> Our thinking was that if you had two running at close to the same time, the
> first transact
We have been using the model of updating certain data in a table of
begin;
delete from foo where bar='myfoo';
insert into foo all of the correct data for myfoo;
commit;
Our thinking was that if you had two running at close to the same time, the
first transaction would finish and then the second o
On 2019-Aug-05, Tom Lane wrote:
> FWIW, I suspect the hard part would be dealing with cases where the
> extremal ranges (according to the index) contain no live tuples
> (according to the query's snapshot). The btree case handles the
> invisible-tuples problem by continuing a scan started at the
As a note to the original poster, you might want to check out-
https://www.postgresql.org/docs/current/citext.html
Alvaro Herrera writes:
> For btrees, we have planagg.c which transforms min() and max() into
> subqueries (SELECT .. WHERE ... ORDER BY .. LIMIT 1).
> In a BRIN index, you could execute the search by scanning the index to
> determine which ranges contain the least/greatest values, and then using
On 2019-Aug-05, Jeremy Finzel wrote:
> Thanks Tom. So, this is a very general question, but would it be possible
> to develop that feature into BRIN, given what it stores? Even if it does
> not have ordering information, doesn't it know which blocks would contain
> the lowest values, so it could
Thanks for your reply Alban. Currently we only have A->B replication. Is adding
B->C replication difficult? I remember in the past I tried to seed
pg_basebackup from hot standby, and it was erroring out after awhile, so needed
to switch to run from master.
From:
Jeremy Finzel writes:
> Thanks Tom. So, this is a very general question, but would it be possible
> to develop that feature into BRIN, given what it stores?
You'd need somebody who knows more about BRIN than me to opine on that.
regards, tom lane
Well, I used only domains with fixed sizes.
create domain i32 as integer;
create domain i16 as smallint;
create domain datahora as timestamp;
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
>
> Yes: BRIN indexes don't provide any ordering information. A btree
> index on created_at could be used to optimize this query, but without
> one of those, seqscanning the whole table is the only possibility.
>
Thanks Tom. So, this is a very general question, but would it be possible
to develo
Jeremy Finzel writes:
> I have a very large table with 4 billion rows and a BRIN index on timestamp
> spanning from 2013 to present. I am running this simple query:
> SELECT MIN(created_at) FROM table;
> It is choosing a parallel seq scan as opposed to a BRIN bitmap scan.
> I can provide more in
PegoraroF10 writes:
> So, the question is, when I create a table using domains it creates a toast
> for it, why ?
For me, this doesn't happen for domains over fixed-width types, only
variable-width types ... which doesn't seem to match your example.
The reason it happens for variable-width cases
Hello -
I have started to make much more use of BRIN indexes on timestamp fields on
tables which are insert-only. I have seen great performance with these and
of course far less overhead.
However, I am noticing that a simple aggregate is not using the index. I
don't find anything obvious in the
> >Hi,
> >
> >On RHEL/Centos you can use VDO filesystem compression to make an archive
> >tablespace to use for older data. That will compress everything.
>
> Doesn't this imply that either his table is partitioned or he
> regularly moves records from the main table to the archive table?
>
Hi,
On 8/5/19 7:31 AM, Kenneth Marshall wrote:
On Mon, Aug 05, 2019 at 12:00:14PM +0530, Shital A wrote:
Hello,
Need inputs on below:
We are working on a setting up a new highly transactional (tps 100k) OLTP
system for payments using blockchain and postgresql 9.6 as DB on Rhel 7.6.
Postgres versio
On Mon, Aug 05, 2019 at 12:00:14PM +0530, Shital A wrote:
> Hello,
>
> Need inputs on below:
>
> We are working on a setting up a new highly transactional (tps 100k) OLTP
> system for payments using blockchain and postgresql 9.6 as DB on Rhel 7.6.
> Postgres version is 9.6 and not latest because
select count(*) Total_Tables,
count(*) filter (where t2.oid is not null) Toasted_Tables,
count(*) filter (where t2.reltuples > 0) Toasted_with_records
from pg_class t1 left join pg_class t2 on t1.reltoastrelid = t2.oid and
t2.relkind = 't'
where t1.relkind = 'r'
total_tablestoast
On 5 Aug 2019, at 0:39, Julie Nishimura wrote:
Alban, thank you for your reply. Your suggestion makes sense, and I will be
talking to our engineers about it. Currently we need to understand:
a) How do we break A -> B replication such that both can become
independent primaries
That is pre
> because of specs of blockchain component.
Based on this schema (
https://grisha.org/blog/2017/12/15/blockchain-and-postgres/ AND
https://github.com/blkchain/pg_blkchain )
and
IF (your) blockchain component is using BYTEA everywhere ( binary data
type : https://www.postgresql.org/docs/9.6/dat
On Mon, 5 Aug 2019, 12:42 Ron, wrote:
> On 8/5/19 1:30 AM, Shital A wrote:
> > Hello,
> >
> > Need inputs on below:
> >
> > We are working on a setting up a new highly transactional (tps 100k)
> OLTP
> > system for payments using blockchain and postgresql 9.6 as DB on Rhel
> 7.6.
> > Postgres ver
po 5. 8. 2019 v 10:10 odesÃlatel Thomas Kellerer
napsal:
> Pavel Stehule schrieb am 05.08.2019 um 08:19:
> >>> I have seen some hacks suggesting TRY/CATCH or converting to a JSON
> >>> and checking if the field exists, but I would think that there's a
> >>> better way to check if the field is in
Pavel Stehule schrieb am 05.08.2019 um 08:19:
>>> I have seen some hacks suggesting TRY/CATCH or converting to a JSON
>>> and checking if the field exists, but I would think that there's a
>>> better way to check if the field is in the NEW record, no?
>
>> I assume using to_jsonb(new) and then che
On 8/5/19 1:30 AM, Shital A wrote:
Hello,
Need inputs on below:
We are working on a setting up a new highly transactional (tps 100k) OLTP
system for payments using blockchain and postgresql 9.6 as DB on Rhel 7.6.
Postgres version is 9.6 and not latest because of specs of blockchain
component
33 matches
Mail list logo
