You should pick one list to post to.
On Tue, Jan 16, 2018 at 4:36 AM, Abhra Kar wrote:
> Hi
> I tried to modify below sql command in postgres syntax---
>
> insert into (id, groupid, ele_id, ro_element_id) ")
>
That ") looks wrong...
select .nextval, :groupid, gosp.net
On 17 January 2018 at 00:36, Abhra Kar wrote:
> insert into (id, groupid, ele_id, ro_element_id) ")
> select .nextval, :groupid, gosp.neteleid, gosp.hodev
>from net_ele gos, net_gos_prop gosp "
>where gos.eid in ( :eids ) and gos.id = gosp.net_element_id
Hi all
Sorry, but I'm not sure that this doubt is appropriate for this list, but I
do need to prepare the file system of an SSD disk in a way that pointed me
to, which would be a way optimized SSD
to work. I have a disk: SSD: Samsung 500 GB SATA III 6Gb/s - Model: 850 Evo
http://www.samsung.com/s
We are seeing these "ERROR: unexpected chunk number 0 (expected 1) for
toast value 1498303849 in pg_toast_10919630" in increasing numbers again¹.
An observation is that they seem to only happen for tsvector fields.
Here is an example sequence of queries for a record (we have more than a
handful
Hi
I tried to modify below sql command in postgres syntax---
insert into (id, groupid, ele_id, ro_element_id) ")
select .nextval, :groupid, gosp.neteleid, gosp.hodev
from net_ele gos, net_gos_prop gosp "
where gos.eid in ( :eids ) and gos.id = gosp.net_ele
On Tue, Jan 16, 2018 at 7:47 AM, Neto pr wrote:
> Hi all
>
> Sorry, but I'm not sure that this doubt is appropriate for this list, but I
> do need to prepare the file system of an SSD disk in a way that pointed me
> to, which would be a way optimized SSD
> to work. I have a disk: SSD: Samsung 500
Hi,
I have two tables in the same database: geoname and test_table.
The geoname table contains many columns which are: name, feature_class,
feature_code, admin1, admin2,admin3, name and so on.
The second table 'test_table' contains only the columns: city, state.
There is no join between the two tab
Sorry I forget the lower command when I wrote the code, it is like this:
lower(g.country_code) like lower('US')
(lower(g.feature_class) like lowwer('P') or lower(g.feature_class) like
lower('L'))
2018-01-16 17:40 GMT+01:00 Martin Moore :
>
>
> >Hi,
>
> >I have two tables in the same database: ge
Do you have any indecies?
https://www.postgresql.org/docs/current/static/indexes-expressional.html
might be helpful to you.
Also, EXPLAIN will help you understand how your query is being run and
where it can be improved.
https://www.postgresql.org/docs/current/static/using-explain.html
http://pos
On Tue, Jan 16, 2018 at 11:46 AM, James Keener wrote:
> Do you have any indecies? https://www.postgresql.org/
> docs/current/static/indexes-expressional.html might be helpful to you.
>
> Also, EXPLAIN will help you understand how your query is being run and
> where it can be improved.
>
> https:/
> On 16 Jan 2018, at 17:32, hmidi slim wrote:
>
> Hi,
> I have two tables in the same database: geoname and test_table.
> The geoname table contains many columns which are: name, feature_class,
> feature_code, admin1, admin2,admin3, name and so on.
> The second table 'test_table' contains only
Hi
2018-01-16 17:44 GMT+01:00 hmidi slim :
> Sorry I forget the lower command when I wrote the code, it is like this:
> lower(g.country_code) like lower('US')
> (lower(g.feature_class) like lowwer('P') or lower(g.feature_class) like
> lower('L'))
>
please, don't do top post.
Your query must be
On Tue, Jan 16, 2018 at 08:02 Scott Marlowe wrote:
> On Tue, Jan 16, 2018 at 7:47 AM, Neto pr wrote:
> > Hi all
> >
> > Sorry, but I'm not sure that this doubt is appropriate for this list,
> but I
> > do need to prepare the file system of an SSD disk in a way that pointed
> me
> > to, which wou
I changed the operator like and I'm using the operator = .I got the results
much faster but I still have another question about operator. For
difference should I use '<>' or 'is distinct from' with indexes?
2018-01-16 17:49 GMT+01:00 Pavel Stehule :
> Hi
>
> 2018-01-16 17:44 GMT+01:00 hmidi slim
Hi Adam , I've been seeing this same kind of Error in my clusters for a while .
Is this running on postgresql 9.4.8? Because mine was fixed upgrading to 9.4.11
, a bug indeed .
Kind regards
Jorge Daniel Fernandez
From: Adam Sjøgren
Sent: Tuesday, January
Hi
2018-01-16 18:57 GMT+01:00 hmidi slim :
> I changed the operator like and I'm using the operator = .I got the
> results much faster but I still have another question about operator. For
> difference should I use '<>' or 'is distinct from' with indexes?
>
https://en.wikipedia.org/wiki/Posting_
2018-01-16 8:50 GMT-08:00 Michael Loftis :
>
> On Tue, Jan 16, 2018 at 08:02 Scott Marlowe
> wrote:
>
>> On Tue, Jan 16, 2018 at 7:47 AM, Neto pr wrote:
>> > Hi all
>> >
>> > Sorry, but I'm not sure that this doubt is appropriate for this list,
>> but I
>> > do need to prepare the file system of
Thank you for your advices and thanks for all people who give me some best
practises and useful ideas.
2018-01-16 19:35 GMT+01:00 hmidi slim :
> Thank you for your advices and thanks for all people who give me some best
> practises and useful ideas.
>
you are welcome
Regards
Pavel
Hi Jorge,
This sounds very interesting - we are running PostgreSQL 9.3.20.
Did you ever find out exactly what the change that solved the problem
between 9.4.8 and 9.4.11 was?
Best regards,
Adam
Jorge writes:
> Hi Adam , I've been seeing this same kind of Error in my clusters for a
Hi Hmidi,
On 17/01/18 06:57, hmidi slim wrote:
I changed the operator like and I'm using the operator = .I got the
results much faster but I still have another question about operator.
For difference should I use '<>' or 'is distinct from' with indexes?
2018-01-16 17:49 GMT+01:00 Pavel Stehul
On Tue, 16 Jan 2018 16:50:28 +, Michael Loftis
wrote:
>Alignment definitely makes a difference for writes. It can also make a
>difference for random reads as well since the underlying read may not line
>up to the hardware add in a read ahead (at drive or OS Level) and youre
>reading far more
I am looking at a database with a wide (~500G) divergence between the total
space expended by the database directory and the result of select
sum(pg_relation_size(oid)) from pg_class;.
I located about 280G of apparent extra space by performing an anti-join
between files on disk and files in the ca
Daniel Farina writes:
> I am looking at a database with a wide (~500G) divergence between the total
> space expended by the database directory and the result of select
> sum(pg_relation_size(oid)) from pg_class;.
Odd.
> I located about 280G of apparent extra space by performing an anti-join
> be
On Tue, Jan 16, 2018 at 3:04 PM Tom Lane wrote:
> Daniel Farina writes:
> > I am looking at a database with a wide (~500G) divergence between the
> total
> > space expended by the database directory and the result of select
> > sum(pg_relation_size(oid)) from pg_class;.
>
> Odd.
>
> > I located
Daniel Farina writes:
> On Tue, Jan 16, 2018 at 3:04 PM Tom Lane wrote:
>> Umm ... are you accounting for catalogs that have zeroes in
>> pg_class.relfilenode? It's generally better to rely on the
>> pg_relation_filenode(oid) function than the raw column contents.
> Yeah, the catalogs are not c
On Tue, Jan 16, 2018 at 07:05:19PM +0100, Adam Sjøgren wrote:
> This sounds very interesting - we are running PostgreSQL 9.3.20.
Which means that we may be looking at a new bug, 9.3.20 is the latest in
the 9.3 set as of today.
> Did you ever find out exactly what the change that solved the proble
Hi All,
Can you please help me to understand what is parallel btree index scan in
Postgres 10.
And what is the difference between index scan and index only scan.
Thanks,
Krithika
Michael writes:
> On Tue, Jan 16, 2018 at 07:05:19PM +0100, Adam Sjøgren wrote:
>> This sounds very interesting - we are running PostgreSQL 9.3.20.
> Which means that we may be looking at a new bug, 9.3.20 is the latest in
> the 9.3 set as of today.
Yes; unfortunately we have failed to reproduc
29 matches
Mail list logo
