On Fri, 2 Dec 2022 at 12:21, Justin Pryzby wrote:
> Could you show explain analyze ?
>
> Show the size of the table and its indexes
> And GUC settings
> And the "statistics" here:
>
> https://wiki.postgresql.org/wiki/Slow_Query_Questions#Statistics:_n_distinct.2C_MCV.2C_histogram
> Maybe on both
Hi there,
I'm wondering if anyone has any insight into what might make the database
choose a sequential scan for a query (table defs and plan below) like :
SELECT orders.orderid FROM orders
WHERE (
orders.orderid IN ('546111')
OR
orders.orderid IN (select orderid FROM orderstotrans WHERE
On Wed, 24 Mar 2021 at 00:07, Rick Otten wrote:
>
>> Yes, the columns are highly correlated, but that alone doesn't seem like
>> it should be sufficient criteria to choose this plan.
>> Ie the selection criteria (1 day of data about a year ago) has a year+
>> worth of data after it and probably
On Tue, 23 Mar 2021 at 16:13, Justin Pryzby wrote:
> On Tue, Mar 23, 2021 at 03:00:38PM +1100, Paul McGarry wrote:
> > I have a query where Postgresql (11.9 at the moment) is making an odd
> plan
> > choice, choosing to use index scans which require filtering out millions
>
th time
zone))
Planning Time: 0.091 ms
Execution Time: 30.045 ms
(5 rows)
==
My count() hack works around my immediate problem but I'm trying to get my
head round why Postgres chooses the plan it does without it, in case there
is some general problem with my configuration that may negatively effect
other areas, or there's something else I am missing.
Any ideas?
Paul McGarry
Hi Didier,
Yes, credit cards are a very specific space that probably gets people who are
familiar with it going a bit. By the time you factor in general security
practices, specific PCI requirements, your threat model and likely business
requirements (needing relatively free access to parts of
Hi Didier,
I’m sorry to tell you that you are probably doing something (ie
handling/storing credit cards) which would mean you have to comply with PCI DSS
requirements.
As such you should probably have a QSA (auditor) who you can run any proposed
solution by (so you know they will be
I haven’t looked up what pgp_sym_encrypt() does but assuming it does encryption
the way you should be for credit card data then it will be using a random salt
and the same input value won’t encrypt to the same output value so
WHERE cc=pgp_sym_encrypt('test value 32', 'motdepasse');
