so many variables involved with doing that ... I don't think
anyone can reliably answer that question.
I recommend you put together a periodic test schedule where you restore
a machine from the backup and ensure everything works. To be honest, you
should be doing that anyway.
--
PT <wmo...@pot
h vectors that
don't require changing the application.
Real security will require changing the application. But take my word for it,
nobody wants to hear the list of breach vectors that can only be fixed by
modifying the application. Because people aren't interested in real security,
they'
On Mon, 24 Jul 2017 13:17:56 +0300
Dmitry Lazurkin <dila...@gmail.com> wrote:
> On 07/24/2017 01:40 AM, PT wrote:
> > In this example you count approximately 40,000,000 values, which is
> > about 40% of the table.
>
> 4 000 000 (:
>
> > If you really need
se ?
> id::text;
> Planning time: 0.114 ms
> Execution time: 9277.307 ms
>
>
> IN-VALUES clause has the bestest perfomance. So I have some questions:
>
> - May be exist better solution?
> - Does PostgreSQL have support of hashset structure? Extension (I don't
> found)?
> - IN-VALUES clause adds new node to plan. Has additional node big overhead?
> How about filter by two or more IN-VALUES clause?
>
> Thanks.
--
PT <wmo...@potentialtech.com>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ke so long that it can't keep up. In theory, setting it too low
can cause autovaccum to have a negative performance impact, but I've never seen
that happen on modern hardware.
But that's all speculation until you know how frequently autovacuum runs on
that table and how long it takes to do its work.
developers will start to complain about
database "errors" once you enable that, as connections will get killed and
cause errors on the application. You'll need to work to educate your
developers on how to fix their application so the situation stops happening.
--
PT <wmo...@potentialtech.com>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
free connections, then your assessment might be correct. But he hasn't
provided enough information to be sure of that.
Regardless, lots of "idle in transaction" connections that stick around a
long time is a clear sign of application bugs. If they're not the cause
of his immediate problem, they will be the cause of problems at some point,
so he might as well track them down and fix them.
--
PT <wmo...@potentialtech.com>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
(cost=0.28..51767.41 rows=62033 *width=272*)
- CTE Scan on poly s (cost=0.00..62.18 rows=3109 width=250)
On Wed, May 27, 2015 at 4:31 PM, PT wmo...@potentialtech.com wrote:
On Tue, 26 May 2015 12:52:24 -0500
David Haynes II dahay...@umn.edu wrote:
Hello,
I have
=1)
- CTE Scan on rast_select r (cost=0.00..1240.66 rows=62033
width=254) (actual time=257.625..863555.082 rows=7677 loops=1)
Total runtime: 866691.113 ms
On Fri, May 29, 2015 at 6:40 AM, PT wmo...@potentialtech.com wrote:
On Thu, 28 May 2015 10:06:24 -0500
David Haynes II dahay
On Fri, 29 May 2015 09:39:00 -0400
Daniel Begin jfd...@hotmail.com wrote:
Hi all,
Running some queries, I found that the planner often selects sequential scan
instead of an index scan, even if the latter is way faster (one order of
magnitude faster if I consider some tests I made by setting
Well, whether good or bad, my employer has nixed the idea of paying me
to work on this, and I don't have personal time right now to do it,
so it's not going to be addressed by me at this time.
--
Bill wmo...@potentialtech.com
--
Sent via pgsql-general mailing list
On Tue, 26 May 2015 12:52:24 -0500
David Haynes II dahay...@umn.edu wrote:
Hello,
I have a question about the query optimizer and its performance on spatial
datasets, specifically rasters. My use case is rather unique, the
application that I am developing allows users to request
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
--
PT wmo...@potentialtech.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
and shall be suitably acknowledged.
This section of the documentation should tell you everything you
need to know:
http://www.postgresql.org/docs/9.4/static/information-schema.html
--
PT wmo...@potentialtech.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
learning, then it might still
be worth it, but it's hardly an idea setup for that kind of thing.
--
PT wmo...@potentialtech.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
the postgresql.conf, read through it to understand where
PostgreSQL is logging, then go look at the PostgreSQL logs.
There's a 90% chance that there will be a detailed message in
the logs that will help you quickly resolve the problem. If not,
you can increase the log verbosity.
--
PT wmo
that would make sense for
me.
Thank you.
Andrzej
--
PT wmo...@potentialtech.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
17 matches
Mail list logo
