I’ve got it now, thank you for the clarification. You are right.
Martin Kováčik
+421904236791
> On 26 Apr 2019, at 00:25, Adrian Klaver wrote:
>
>> On 4/25/19 1:28 PM, Martin Kováčik wrote:
>> I'm not sure if I understand what you mean. My initial thought was that
>> stats are fixed per transa
On 4/25/19 1:28 PM, Martin Kováčik wrote:
I'm not sure if I understand what you mean. My initial thought was that
stats are fixed per transaction, i.e. analyze from comitted transaction
doesn't interfere with another running transaction. Maybe I was confused
by this because analyze can be run i
Piotr Findeisen writes:
> I think I need to provide some context for my question.
> ...
> When accessing a table in Postgres, we need to map columns' types to
> appropriate types in Presto.
> For mapping arrays, we need to know number of array dimensions.
> Currently we read this from pg_attribute
Piotr Findeisen writes:
> Internally, array types get a name in the form of `_`.
Typically, yes.
> *Can a user use `_` to define a column of array type?*
Sure ... didn't you try it?
> *Is it supported?*
Not really, because it's not guaranteed that the name looks like that.
There are various c
Hi,
As documented to
https://www.postgresql.org/docs/11/arrays.html#ARRAYS-DECLARATION one can
create column of an array type using `[]` form.
Internally, array types get a name in the form of `_`.
This is documented
https://www.postgresql.org/docs/11/sql-createtype.html#id-1.9.3.94.5.9
*So -- t
I'm not sure if I understand what you mean. My initial thought was that
stats are fixed per transaction, i.e. analyze from comitted transaction
doesn't interfere with another running transaction. Maybe I was confused by
this because analyze can be run inside a transaction, so my assumption was
it i
Thanks Tom,
that is a great explanation. The default plan, which overestimates number
of rows is much better than the plan (which is based on wrong stats) that
underestimates it. This is true for my particular case but may be bad for
other cases.
The schema is created before the tests begin so th
On 4/25/19 12:47 PM, Martin Kováčik wrote:
As my example shows you don't have to import a lot of rows - 1000 is
enough to make a difference - it all depends on the query. When a
cartesian product is involved only a few records is enough.
I think that stats should be MVCC versioned otherwise the
As my example shows you don't have to import a lot of rows - 1000 is enough
to make a difference - it all depends on the query. When a cartesian
product is involved only a few records is enough.
I think that stats should be MVCC versioned otherwise the planner is using
wrong statistics and chooses
=?UTF-8?B?TWFydGluIEtvdsOhxI1paw==?= writes:
> To illustrate my situation let's consider my tests look like this:
> BEGIN;
> -- A: insert data for the test
> -- B: i'll refer to this point later
> -- C: select(s)
> ROLLBACK;
> Everything is fine, until autovacuum (analyze) runs when the test
On 4/25/19 7:37 AM, Martin Kováčik wrote:
Hi group,
See comments inline below
To illustrate my situation let's consider my tests look like this:
BEGIN;
-- A: insert data for the test
-- B: i'll refer to this point later
-- C: select(s)
ROLLBACK;
Everything is fine, until autovacuum (an
On Thu, Apr 25, 2019, 11:34 AM Martin Kováčik wrote:
> Turning off autovacuum for the tests is a valid option and I will
> definitely do this as a workaround. Each test pretty much starts with empty
> schema and data for it is generated during the run and rolled back at the
> end. I have a lot of
Turning off autovacuum for the tests is a valid option and I will
definitely do this as a workaround. Each test pretty much starts with empty
schema and data for it is generated during the run and rolled back at the
end. I have a lot of tests and at the moment it is not feasible to modify
them.
Th
I assume it is in the documentation, but I am not aware of how stats are
handled for uncommitted work. Obviously in the example you provided the
table would be empty, but in your real tests do they start out empty? Would
it suffice to use temp tables created like the regular ones and analyze
after
Hi group,
I have a Jenkins build server which runs integration tests of a Java
application against PostgreSQL 11.2. The tests run in serial fashion and
are reproducible because each test runs in separate DB transaction which is
rolled back at the end of each test. Each full build (with 1400+ tests
On 2019-Apr-25, rihad wrote:
> Hi. Say I have column A.b_id which references B.id (which is a primary key)
> and as such it is declared as a foreign key constraint. A.b_id has no index
> because it doesn't need one. What happens when table B's rows are modified
> (but never deleted)? Will PG still
Hi. Say I have column A.b_id which references B.id (which is a primary
key) and as such it is declared as a foreign key constraint. A.b_id has
no index because it doesn't need one. What happens when table B's rows
are modified (but never deleted)? Will PG still have have to scan A fo
find A.b_i
17 matches
Mail list logo
