On Mon, Sep 23, 2019 at 7:23 PM Adrian Klaver
wrote:
> "Once restored, it is wise to run ANALYZE on each restored table so the
> optimizer has useful statistics; see Section 24.1.3 and Section 24.1.6
> for more information."
>
> So is there some other step in the process that occurs after the res
On Mon, Sep 23, 2019 at 5:51 PM Adrian Klaver
wrote:
> Usually what is seen here is the opposite, that tables are restored and
> ANALYZE is not run and performance on the subsequent queries is poor due
> to lack of current statistics.
>
> What is the restore process?
>
For these specific legacy
On Mon, Sep 23, 2019 at 4:50 PM Adrian Klaver
wrote:
> Smaller hammer:
>
>
> https://www.postgresql.org/docs/11/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS
>
> "autovacuum_enabled, toast.autovacuum_enabled (boolean)"
>
> which can be done by ALTER TABLE also:
>
> https://www.postgresq
On Mon, Sep 23, 2019 at 4:31 PM Adrian Klaver
wrote:
> Hmm, are there triggers on wss_entries that are UPDATEing/DELETEing
> entries elsewhere?
>
No, that table is pretty much stand-alone. What we're seeing here is most
likely caused by the initial copy of the legacy db tables.
This happens wh
On Mon, Sep 23, 2019 at 9:22 AM Adrian Klaver
wrote:
> Can we see the actual function/query?
>
> Also the schema of the table(s) involved?
>
Of course. This was added to pull some data from legacy db tables into
something we could query while converting the process that populates the
legacy db.
On Mon, Sep 23, 2019 at 8:57 AM Tom Lane wrote:
> Maybe check for waiting on a lock?
> It'd be useful to look in pg_stat_activity and/or top(1) while the
> initial query is running, to see if it seems to be eating CPU or
> is blocked on some condition.
>
I think this will provide information tha
>
> First thing I'd look at is whether it's the same execution environment
> in both cases, eg same search_path.
>
As far as I can tell, it's the same execution environment, same search_path
and same user.
I found after testing other situations, that the psql command would always
finish as expect
If this is a common question or an article exists, please let me know. I
couldn't find anything specific about it in stack overflow questions or
postgres/psql documentation.
This is in PostgreSQL 9.6.
I am trying to figure out how to debug an issue where a function
'import_wss' called through pg
On Sat, Jan 6, 2018 at 12:30 PM, Melvin Davidson
wrote:
>
> *Don't forget to create indexes on the FK's in the table they reference!*
>
>
> *Also, it would be nice to know the PostgreSQL version and O/S.*
>
Is it possible for an index to not exist on those columns?
https://www.postgresql.org/d
On Sun, Dec 24, 2017 at 1:11 AM, Daevor The Devoted
wrote:
>
> Le 23 déc. 2017 20:25, "Peter J. Holzer" a écrit :
>
> I think the OP wants something like this:
>
> create table features (
> id serial primary key,
> name varchar not null
> );
>
> create table products (
> id serial pr
On Mon, Dec 18, 2017 at 11:01 AM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> Do you mean:
>
> SELECT id, val, val / (sum(val) OVER ())
> FROM vals;
>
You could end up with a percentage > 100 or divide by 0 with that if the
values are not in a proper range. I don't know if that w
On Mon, Dec 18, 2017 at 2:18 AM, Tom Dunstan wrote:
>
>>
>> A timestamptz stores everything as UTC and the value is converted to the
session time zone upon retrieval.
>
>
> Which is exactly what we want.
If a random person can interject here, I believe what Tom Dunstan is asking
about here is the
> But for simple queries, you might get some insight if you set
> enable_seqscan to off. Then the planner will give you an index-using
> plan if it is at all possible. Then you can compare the costs. If the
> planner still gives you a sequential scan, then the index was not
> applicable for othe
This isn't meant to be a question about improving a slow query or
determining that the planner was wrong.
It seems like a simple and obvious answer, but I would love to know if
there is any documentation you can point me to read on this.
Essentially, if an index was deemed not to save cost during
14 matches
Mail list logo
