>> I am trying to understand how to use the full-text search parser for
>> URLS and hostnames to filter results from a text field containing URLS
>> based on domain, and also how to index text columns for fast
>> lookup/matching based on domain.
>> >> I have a PostgreSQL database containing documen
I am trying to understand how to use the full-text search parser for
URLS and hostnames to filter results from a text field containing URLS
based on domain, and also how to index text columns for fast
lookup/matching based on domain.
I have a PostgreSQL database containing documents and links down
Thanks Tom for the explanation. I assumed it was my ignorance of how the schema
was handled that was making this look like a problem that had already been
solved and I was missing something.
I fully expected the "You're Doing It Wrong" part. That is out of my control
but not beyond my influence
On 4/6/19 6:50 PM, Tom Lane wrote:
senor writes:
[snip]
The --link option to pg_upgrade would be so much more useful if it
weren't still bound to serially dumping the schemas of half a million
tables.
To be perfectly blunt, if you've got a database with half a million
tables, You're Doing It
senor writes:
> Is the limitation simply the state of development to date or is there
> something about dumping the schemas that conflicts with paralleling?
At minimum, it'd take a complete redesign of pg_dump's output format,
and I'm not even very sure what such a redesign would look like. All
Thanks Tom. I suppose "pg_dump can only parallelize data dumping" answers my
original question as "expected behavior" but I would like to understand the
reason better.
My knowledge of Postgres and other DBMSs is at casual admin level with the
occasional deep dive on specific errors or analysis.
senor writes:
> Since pg_upgrade is in control of how it is calling pg_dump, is there a
> reason pg_upgrade cannot use the directory output format when calling
> pg_dump? Is the schema-only operation incompatible?
Well, there's no point in it. pg_dump can only parallelize data dumping,
and the
Thank you for responding. I did see that note and should have included that as
part of my question.
Since pg_upgrade is in control of how it is calling pg_dump, is there a reason
pg_upgrade cannot use the directory output format when calling pg_dump? Is the
schema-only operation incompatible?
On 4/6/19 11:44 AM, senor wrote:
The pg_upgrade --jobs option is not passed as an argument when it calls
pg_dump. I haven't found anything in docs or forums mentioning a reason for not
supporting under certain circumstances other than possibly for pre-9.2. The
pg_upgrade docs page states that
The pg_upgrade --jobs option is not passed as an argument when it calls
pg_dump. I haven't found anything in docs or forums mentioning a reason for not
supporting under certain circumstances other than possibly for pre-9.2. The
pg_upgrade docs page states that it allows multiple CPUs to be used
Guys, still need your help.
Previous night:
*2019-04-05 00:35:04 UTC LOG: could not truncate directory "pg_serial":
apparent wraparound*
*2019-04-05 00:40:04 UTC LOG: could not truncate directory "pg_serial":
apparent wraparound*
(2 checkpoints)
It turned that I have some problem with perform
Hi. When master server receives smart shutdown request (TERM) does it
exit after making sure it sends all received writes to the slave
server(s), or it exits leaving the slave in an inconsistent state? What
about during fast shutdown (SIGINT)? I know that it asks current
requests to terminate i
12 matches
Mail list logo
