; grant usage on schema ap to rs;
> Insert into ap.table1 values (12)
>
>
> Can anyone explain how the FK constraint function works? Is it executed as
> the owner of the object. That is the only thing that would make sense for
> me.
>
> Thank you.
>
> Andrzej
--
PT
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
e b.
> Please help me in resolving this error.
Find 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,
yo
it in mind; since you'll likely
see the same variance on production.
If you're doing it for your own general learning, then it might still
be worth it, but it's hardly an idea setup for that kind of thing.
--
PT
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
at they used. I
> appreciate all your help 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
--
Sent via pgsql-general mailing list (pgsql-general@po
gt; > > file were approx. 3. Due to archiving pg_xlog folder size is
> > > decreasing now but it’s taking one week to come in normal size.
> >
> > Any chance you have unfinished transactions running for a week?
> >
> > pg_stat_activity should be able to
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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to yo
On Tue, 26 May 2015 12:52:24 -0500
David Haynes II 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 summarizations of
> var
-> CTE Scan on poly s (cost=0.00..62.18 rows=3109 width=250)
>
>
> In DB
> Nested Loop (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 wrote:
On Fri, 29 May 2015 09:39:00 -0400
Daniel Begin 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 enable_seqsca
mp; s.geom)
> Filter: _st_intersects(s.geom, rast, NULL::integer)
> Rows Removed by Filter: 0
> -> HashAggregate (cost=17214.16..17276.20 rows=6204 width=254) (actual
> time=866317.923..866320.316 rows=7612 loops=1)
> -> CTE S
ssment 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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
omplain 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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ong 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 d
ot;: null', ',') ||
> '}''::jsonb') AS jsonb_clause
> FROM (SELECT id FROM ids GROUP BY id ORDER BY id LIMIT 200) AS s \gset
>
> EXPLAIN (ANALYZE, BUFFERS) SELECT count(*) FROM ids WHERE :jsonb_clause ?
> 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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Mon, 24 Jul 2017 13:17:56 +0300
Dmitry Lazurkin 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 these queries
ects againts possible breach 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
oing 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
--
Sent via pgsql-general m
17 matches
Mail list logo
