Thank you. Is there a way to find out if I have tables with tsvectors or
indexes? I have hundreds of tables...
From: Tom Lane
Sent: Tuesday, April 16, 2019 9:45 PM
To: Julie Nishimura
Cc: Adrian Klaver; pgsql-general@lists.postgresql.org
Subject: Re: text search
Julie Nishimura writes:
> Thank you guys. I've dumped the schema and was able to load it properly this
> time. There were some missing text search dictionaries, fts templates and
> functions. I was able to recreate it. Now is my question - do I need to
> reload the data?
The base textual data
Thank you guys. I've dumped the schema and was able to load it properly this
time. There were some missing text search dictionaries, fts templates and
functions. I was able to recreate it. Now is my question - do I need to reload
the data?
Thanks!
From: Adria
On 4/16/19 4:22 PM, Julie Nishimura wrote:
Adrian, Hitwise is the name of our company. Unfortunately, it does not
help to find how I can migrate missing search config or install whatever
is on 8.3. I did not restore the entire database (due to its large
size), I've dumped and restored just abou
On 4/16/19 4:22 PM, Julie Nishimura wrote:
Adrian, Hitwise is the name of our company. Unfortunately, it does not
Aah that would explain it.
help to find how I can migrate missing search config or install whatever
is on 8.3. I did not restore the entire database (due to its large
size), I've
Adrian, Hitwise is the name of our company. Unfortunately, it does not help to
find how I can migrate missing search config or install whatever is on 8.3. I
did not restore the entire database (due to its large size), I've dumped and
restored just about 200 hundred tables they needed on staging.
On 4/16/19 1:55 PM, Julie Nishimura wrote:
Oh thank you for answering me!!!
Another thing:
source (8.3):
\dF
List of text search configurations
Schema | Name | Description
++---
On 4/16/19 2:46 PM, Tom Lane wrote:
Julie Nishimura writes:
1) This is the 8.3 source:
select * from pg_ts_dict;
...
english_stem_nostop | 21960 |10 |11282 | language =
'english'
hwsplit | 21960 |10 |22342 |
hwsplit_only
Julie Nishimura writes:
> 1) This is the 8.3 source:
> select * from pg_ts_dict;
> ...
> english_stem_nostop | 21960 |10 |11282 | language =
> 'english'
> hwsplit | 21960 |10 |22342 |
> hwsplit_only| 21960 |10
On 4/16/19 2:04 PM, Zahir Lalani wrote:
Hi
Is this the same for the other environments?
We have recently upgraded others to 10 and are in testing before we upgrade
production. However we still some 9.6 dev servers which are fine.
I am not following above.
What is running version 10?
Did
Hi
>Is this the same for the other environments?
We have recently upgraded others to 10 and are in testing before we upgrade
production. However we still some 9.6 dev servers which are fine.
>What does:
>SHOW lc_collate;
en_US.UTF-8
>Are you doing the below through Navicat or psql?
Using Na
Oh thank you for answering me!!!
1) This is the 8.3 source:
select * from pg_ts_dict;
dictname | dictnamespace | dictowner | dicttemplate |
dictinitoption
-+---+---+--+
On 4/16/19 12:02 PM, Julie Nishimura wrote:
Correction: tables are not missing, but some records from the tables
missing. How can we migrate them properly from 8.3 to 9.4?
This is going to need some more info:
1) What records?
2) 8.3 was the version where text search was integrated into core.
Correction: tables are not missing, but some records from the tables missing.
How can we migrate them properly from 8.3 to 9.4?
Sent from my iPhone
On Apr 16, 2019, at 10:32 AM, Julie Nishimura
mailto:juliez...@hotmail.com>> wrote:
Hello, we recenlty created fresh install of 9.4, created new d
Hello, we recenlty created fresh install of 9.4, created new dbs, and pg_dumped
and restored correspondent dbs from 8.3 (pg_dump|psql, being on target). Now
we've noticed that some of `pg_catalog.pg_ts_config` and pg_ts_dict tables are
missing, making text search on 9.4 very slow. We tried to in
On 4/16/19 10:16 AM, Zahir Lalani wrote:
Which version? What are the queries you are running which give unexpected
behavior? Have your run explain analyze on those to check >what plan is being
used? Have your reindexed all or only the one you suspect?
Hi Michael
Version: PostgreSQL 9.6.12 o
>Which version? What are the queries you are running which give unexpected
>behavior? Have your run explain analyze on those to check >what plan is being
>used? Have your reindexed all or only the one you suspect?
Hi Michael
Version: PostgreSQL 9.6.12 on x86_64-pc-linux-gnu, compiled by gcc (G
On 4/16/19 10:02 AM, Zahir Lalani wrote:
Hi All
New on this list!
We have an existing postgres deployment which is showing some odd
behaviour on Live. We use Navicat to manage it, and when we open a
What does Live refer to?
specific table via navicat on live, it says we don’t have a primar
Which version? What are the queries you are running which give unexpected
behavior? Have your run explain analyze on those to check what plan is
being used? Have your reindexed all or only the one you suspect?
>
On 4/16/19 9:18 AM, Tim Kane wrote:
Thanks everyone..
It seems that the first step:
old_type --> varchar(9)
still requires a table rewrite, while the reverse direction does not.
Hmm:
CREATE DOMAIN old_type AS varchar(9);
create table rewrite_test (id integer, fld_1 old_type);
insert into
Hi All
New on this list!
We have an existing postgres deployment which is showing some odd behaviour on
Live. We use Navicat to manage it, and when we open a specific table via
navicat on live, it says we don't have a primary index - although the design
view does show it. We have auto deployme
Thanks everyone..
It seems that the first step:
old_type --> varchar(9)
still requires a table rewrite, while the reverse direction does not.
I'm curious about the performance implication of domain types, i expect
that cost is only at insert/update time? I guess we've been wearing that
cost up
On 4/16/19 9:42 AM, Tom Lane wrote:
Adrian Klaver writes:
I suspect the OP wants the type to text with a CHECK constraint to allow
for increasing the length of field values in the future by just changing
the CHECK setting. If that is the case would changing the type to text
and then adding a CH
On 4/16/19 9:28 AM, Adrian Klaver wrote:
On 4/16/19 7:19 AM, Ron wrote:
On 4/16/19 4:22 AM, Tim Kane wrote:
So I have a situation where I would like to modify a field that is
currently a domain type over a varchar(9)
Specifically:
CREATE DOMAIN old_type AS varchar(9)
This isn't ideal, let's
On 4/16/19 7:42 AM, Tom Lane wrote:
Adrian Klaver writes:
I suspect the OP wants the type to text with a CHECK constraint to allow
for increasing the length of field values in the future by just changing
the CHECK setting. If that is the case would changing the type to text
and then adding a CH
Adrian Klaver writes:
> I suspect the OP wants the type to text with a CHECK constraint to allow
> for increasing the length of field values in the future by just changing
> the CHECK setting. If that is the case would changing the type to text
> and then adding a CHECK NOT VALID work without t
"Takahashi, Ryohei" writes:
>> So, if the library gives you an error ( "I have not received the commit
>> confirmation" , not something like "commit failed" ), you will still
>> need to test the data, if you can, to know how the server come back up.
> Yes.
> I want to know what error does library
On 4/16/19 7:19 AM, Ron wrote:
On 4/16/19 4:22 AM, Tim Kane wrote:
So I have a situation where I would like to modify a field that is
currently a domain type over a varchar(9)
Specifically:
CREATE DOMAIN old_type AS varchar(9)
This isn't ideal, let's just say.. legacy.
I wish to modify this
On 4/16/19 4:22 AM, Tim Kane wrote:
So I have a situation where I would like to modify a field that is
currently a domain type over a varchar(9)
Specifically:
CREATE DOMAIN old_type AS varchar(9)
This isn't ideal, let's just say.. legacy.
I wish to modify this type.. ideally to a text type w
On 4/16/19 7:16 AM, Adrian Klaver wrote:
On 4/16/19 7:12 AM, Tom Lane wrote:
Tim Kane writes:
So I have a situation where I would like to modify a field that is
currently a domain type over a varchar(9)
Specifically:
CREATE DOMAIN old_type AS varchar(9)
I wish to modify this type.. ideally
On 4/16/19 7:12 AM, Tom Lane wrote:
Tim Kane writes:
So I have a situation where I would like to modify a field that is
currently a domain type over a varchar(9)
Specifically:
CREATE DOMAIN old_type AS varchar(9)
I wish to modify this type.. ideally to a text type with a length
constraint..
Tim Kane writes:
> So I have a situation where I would like to modify a field that is
> currently a domain type over a varchar(9)
> Specifically:
> CREATE DOMAIN old_type AS varchar(9)
> I wish to modify this type.. ideally to a text type with a length
> constraint.. or even just a slightly large
we were able to use a brin index for our time-series data and that saved
a lot of space. basically, we used a btree for recent data and, once the
data was "stable", reclustered the data to get high correlation on the
brin index, created a brin index and dropped the btree. it works well.
On 4/1
On 4/16/19 12:07 AM, Raghavendra Rao J S V wrote:
Hi All,
We are facing below error while taking the backup of the database using
pg_dump. Could you suggest me how to rectify this?
pg_dump: [archiver (db)] query was: COPY public.aclappliedtopep (id,
instance_version, direction, aclname, ifn
David Rowley writes:
> On Tue, 16 Apr 2019 at 20:43, Raghavendra Rao J S V
> wrote:
>> We are facing below error while taking the backup of the database using
>> pg_dump. Could you suggest me how to rectify this?
>> pg_dump: FATAL: terminating connection due to administrator command
> This loo
On Tue, 16 Apr 2019 at 20:43, Raghavendra Rao J S V
wrote:
> We are facing below error while taking the backup of the database using
> pg_dump. Could you suggest me how to rectify this?
>
> pg_dump: [archiver (db)] query was: COPY public.aclappliedtopep (id,
> instance_version, direction, aclnam
So I have a situation where I would like to modify a field that is
currently a domain type over a varchar(9)
Specifically:
CREATE DOMAIN old_type AS varchar(9)
This isn't ideal, let's just say.. legacy.
I wish to modify this type.. ideally to a text type with a length
constraint.. or even just
Hi All,
We are facing below error while taking the backup of the database using
pg_dump. Could you suggest me how to rectify this?
pg_dump: [archiver (db)] query was: COPY public.aclappliedtopep (id,
instance_version, direction, aclname, ifname, owningentityid,
protocolendpoint_id, deploypending
38 matches
Mail list logo
