út 11. 10. 2022 v 7:08 odesílatel gzh napsal:
> Hi, Pavel
>
>
> > The LIMIT clause changes total cost. This is a very aggressive clause.
> And
>
> > although it is absolutely useless in this case, Postgres does not have
> any
>
> > logic for removing it. Postgres doesn't try to fix developer's
Hi, Pavel
> The LIMIT clause changes total cost. This is a very aggressive clause. And
> although it is absolutely useless in this case, Postgres does not have any
> logic for removing it. Postgres doesn't try to fix developer's mistakes.
Sorry,I didn't understand what you mean.
Couldn't
út 11. 10. 2022 v 6:05 odesílatel gzh napsal:
>
> Hi, Pavel
>
> Thank you for your reply.
>
>
> > the LIMIT clause is in this case totally useless and messy, and maybe can
>
> > negative impacts optimizer
>
> Yes. After removing the LIMIT clause, the performance is improved.
>
> The execution
Hi, Pavel
Thank you for your reply.
> the LIMIT clause is in this case totally useless and messy, and maybe can
> negative impacts optimizer
Yes. After removing the LIMIT clause, the performance is improved.
The execution plan shows that the index worked.
We've noticed it, but I don't
út 11. 10. 2022 v 5:13 odesílatel gzh napsal:
> Hi, Tom
> Thank you for your reply.
>
> > When you're asking for help, please don't give us vague statements
>
> > like "doesn't seem to work".
>
> I understand.
>
>
> > Did the plan (including rowcount
>
> > estimates) change at all? To what?
Hi, Tom
Thank you for your reply.
> When you're asking for help, please don't give us vague statements
> like "doesn't seem to work".
I understand.
> Did the plan (including rowcount
> estimates) change at all? To what? How far off is that rowcount
> estimate, anyway --- that is, how
pgp_sym_encrypt uses a random salt each time, so you cannot compare the
output
to p1 like you would do with crypt to verify a given plaintext.
Instead, use
pgp_sym_decrypt with p1 as input to get the plaintext.
--
Erik
Ah! That makes sense. Thanks Erik!
Hi Howard,
> On 11/10/2022 00:25 CEST howardn...@selestial.com wrote:
>
> I am trying out a few pgcrypto functions. I was expecting the final
> select statement to return the row I just inserted - Can anyone tell me
> what I am not understanding here?
>
> create table test (p1 bytea);
>
Hi all,
I am trying out a few pgcrypto functions. I was expecting the final
select statement to return the row I just inserted - Can anyone tell me
what I am not understanding here?
create table test (p1 bytea);
insert into test (pgp_sym_encrypt('123', 'secret'));
select * from test where
On 10/10/22 8:12 AM, Kostas Papadopoulos wrote:
On 10/10/2022 17:53, Tom Lane wrote:
Kostas Papadopoulos writes:
I cannot see how it can be configuration since the two databases are
in the same
Postgres instance.
There is such a thing as ALTER DATABASE ... SET to install different
On 10/10/2022 17:53, Tom Lane wrote:
Kostas Papadopoulos writes:
I cannot see how it can be configuration since the two databases are in the same
Postgres instance.
There is such a thing as ALTER DATABASE ... SET to install different
settings at the per-database level.
I understand, but
Kostas Papadopoulos writes:
> I cannot see how it can be configuration since the two databases are in the
> same
> Postgres instance.
There is such a thing as ALTER DATABASE ... SET to install different
settings at the per-database level.
In general, the answer to your question is that the
On 10/10/22 06:12, Julien Rouhaud wrote:
On Mon, Oct 10, 2022 at 04:05:42PM +0300, Kostas Papadopoulos wrote:
Hi,
Yes, I ran ANALYZE in both databases.
Please look at https://wiki.postgresql.org/wiki/Slow_Query_Questions to provide
more information.
Without the information, as detailed at
On 10/10/2022 16:44, Ron wrote:
How identical is "identical"?
For example, does diff says that "pg_dump --schema-only" of DB1 and DB2 are perfectly
identical?
And are the table counts identical?
I created the second database using pg_dump from the first, so they should be exactly
the
How identical is "identical"?
For example, does diff says that "pg_dump --schema-only" of DB1 and DB2 are
perfectly identical?
And are the table counts identical?
On 10/10/22 08:15, Kostas Papadopoulos wrote:
Hi,
Thank you for responding. My question is not about the performance of a
> Ran analyze on both. Running the same query I'm getting different plans,
one x10 slower.
theory:
the "statistics target" is too low ?
THEN
different random sample --> different statistics ---> different plan,.
*"For large tables, ANALYZE takes a random sample of the table contents,
rather
Hi,
I cannot see how it can be configuration since the two databases are in the same
Postgres instance.
Kostas Papadopoulos
On 10/10/2022 16:16, Pavel Stehule wrote:
po 10. 10. 2022 v 15:12 odesílatel Julien Rouhaud
napsal:
On Mon, Oct 10, 2022 at 04:05:42PM +0300, Kostas Papadopoulos
po 10. 10. 2022 v 15:12 odesílatel Julien Rouhaud
napsal:
> On Mon, Oct 10, 2022 at 04:05:42PM +0300, Kostas Papadopoulos wrote:
> > Hi,
> >
> > Yes, I ran ANALYZE in both databases.
>
This can be a common case. Check your configuration: work_mem,
shared_buffers, effective_cache_size,
Hi,
Thank you for responding. My question is not about the performance of a specific
query. As I wrote, that is already solved.
My question is "how can it be that the same query run in two exactly the same
databases can have different plans."
Kostas Papadopoulos
On 10/10/2022 16:12,
On Mon, Oct 10, 2022 at 04:05:42PM +0300, Kostas Papadopoulos wrote:
> Hi,
>
> Yes, I ran ANALYZE in both databases.
Please look at https://wiki.postgresql.org/wiki/Slow_Query_Questions to provide
more information.
Hi,
Yes, I ran ANALYZE in both databases.
Kostas
On 10/10/2022 16:03, Daevor The Devoted wrote:
Hi
Is the table stats up to date on both?
https://www.postgresql.org/docs/current/planner-stats.html
Best regards,
Na-iem Dollie
On Mon, Oct 10, 2022 at 2:56 PM Kostas Papadopoulos <
Hi
Is the table stats up to date on both?
https://www.postgresql.org/docs/current/planner-stats.html
Best regards,
Na-iem Dollie
On Mon, Oct 10, 2022 at 2:56 PM Kostas Papadopoulos <
kos...@methodosit.com.cy> wrote:
>
> I have two identical databases running in the same instance of
I have two identical databases running in the same instance of Postgresql. Ran
analyze on both. Running the same query I'm getting different plans, one x10 slower.
Although I have solved my problem by re-writing the query, I want to understand why
this is happening. If the configuration,
23 matches
Mail list logo
