On 21/02/2017 01:49, Venkata B Nagothi wrote:
On Tue, Feb 21, 2017 at 6:53 AM, Gabriel Ortiz Lour mailto:ortiz.ad...@gmail.com>> wrote:
Hi!
Thanks for pointing out pg_basebackup
The issue I'm facing now is about missing WAL files.
What i'm doing:
# su postgres -c 'p
What is the execution plan of a query is showing? Check whether it is
reading through all partitions.
Best Regards,
*Sushant Pawar | Database Solution Consultant*
*ASHNIK TECHNOLOGY SOLUTIONS PVT. LTD.*
Skype: sush_531 | T: +91 9769559995 <%2B65%206438%203504> | www.ashnik.com
On Tue, Feb 21,
On Thursday, February 16, 2017, Tom Lane wrote:
> Tim Bellis > writes:
> > Even though this is a read only query, is it also expected to be blocked
> behind the vacuum? Is there a way of getting indexes for a table which
> won't be blocked behind a vacuum?
>
> It's not the vacuum that's blocking
On Tue, Feb 21, 2017 at 6:53 AM, Gabriel Ortiz Lour
wrote:
> Hi!
>
> Thanks for pointing out pg_basebackup
>
> The issue I'm facing now is about missing WAL files.
>
> What i'm doing:
> # su postgres -c 'pg_basebackup -D /var/lib/postgresql/9.1/main/ -x -h
> master -U sa_rep' ; service post
On 02/17/2017 04:53 PM, Arnold Somogyi wrote:
> Hi,
>
> I wonder if there is a way to add more then one ON CONSTRAINT value.
> I have many different unique constraints on my table and I would like to
> catch and handle two of them with ON CONFLICT ON CONSTRAINT. And the
> rest errors will be handl
On Mon, Feb 20, 2017 at 04:22:51PM -0500, Tom Lane wrote:
> One other thought here --- if you do want to go with the "no other
> updates" semantics, it still seems like it should be sufficient to
> compare xmins. Comparing the xmax values would add nothing to that,
> except that it would reject i
Karsten Hilbert writes:
> Also a consideration: table.*::text may become quite unwieldy
> if there's one or more BYTEA columns in the table.
One other thought here --- if you do want to go with the "no other
updates" semantics, it still seems like it should be sufficient to
compare xmins. Compar
On Mon, Feb 20, 2017 at 03:44:49PM -0500, Tom Lane wrote:
> >where table.*::text = (saved from select).
>
> > If the row was changed between the time it was first read and updated, the
> > update will do touch any rows as the ::text will be different.
>
> > Why can't we use xmin and xmax col
Do you have non overlapping check constraints on the partitions by date to
allow the planner to exclude the child tables from needing to be looked at?
Rakesh Kumar writes:
> In the chapter "Using optimistic locking" of the book "PG Cookbook Second
> Edition"
> it is mentioned how the app can first fetch row from the table in the form
> select a.*::text from table a where ...
> Then do the work and then when it comes to committing do it as
>
Hu guys,
we have a test machine with Postgresql 9.6.1 an about 800.000.000 record in a
table.
Table is partitioned by day, with indexes on partitioned table.
Also a simple query (for example i want to search log occurred in a specific
day), is immediate in tha partitioned table (table_2017_02_1
On 2/18/17 at 3:33 AM, Egon Frerich wrote:
I have a table with two columns with type money. If column 'a' has an
amount > 0 then this amount is wanted else the amount from column 'b'.
Examples in 4.2.14
SELECT CASE WHEN a > 0 THEN a ELSE b END FROM
WHERE ;
Regards
Gavan Schneider
--
Se
Hi,
I wonder if there is a way to add more then one ON CONSTRAINT value.
I have many different unique constraints on my table and I would like to
catch and handle two of them with ON CONFLICT ON CONSTRAINT. And the rest
errors will be handled by the client application.
INSERT INTO table_1 (id, na
Hi!
Thanks for pointing out pg_basebackup
The issue I'm facing now is about missing WAL files.
What i'm doing:
# su postgres -c 'pg_basebackup -D /var/lib/postgresql/9.1/main/ -x -h
master -U sa_rep' ; service postgresql start
The idea is to call "postgresql start" as soon as pg_basebac
On Mon, Feb 20, 2017 at 07:27:34PM +, Rakesh Kumar wrote:
> I tested it and it works. what I did was to select xmin and xmax and then
> sleep for a min.
> In the meantime, I update the same row in another session.
> After 1 min the update session failed to update any row because the
> combi
In the chapter "Using optimistic locking" of the book "PG Cookbook Second
Edition"
it is mentioned how the app can first fetch row from the table in the form
select a.*::text from table a where ...
Then do the work and then when it comes to committing do it as
update table
set
On 2/20/2017 5:22 AM, Stephen Frost wrote:
You probably shouldn't be partitioning by day for such a small dataset,
unless you've only got a few days worth of data that make up those 800m
records.
agreed. we do like 6 months retention by weeks, so there's 26 or so
partitions, that is reasonabl
> Unfortunately, that'll require locking each table and scanning it to make
> sure that the CHECK constraint isn't violated.
Actually, CHECK constraints can be added with the NOT VALID clause.
New tuples will be checked immediately, while the validation of existing tuples
can be done later usin
Greetings,
* Job (j...@colliniconsulting.it) wrote:
> here is primary a partitioned table (for 20/2/2017 logs):
> flashstart=# \d webtraffic_archive_day_2017_02_20;
> Table
> "public.webtraffic_archive_day_2017_02_20"
> Column |Type
Hi,
here is primary a partitioned table (for 20/2/2017 logs):
flashstart=# \d webtraffic_archive_day_2017_02_20;
Table
"public.webtraffic_archive_day_2017_02_20"
Column |Type |
Modifiers
Greetings,
* Job (j...@colliniconsulting.it) wrote:
> we have a test machine with Postgresql 9.6.1 an about 800.000.000 record in a
> table.
> Table is partitioned by day, with indexes on partitioned table.
You probably shouldn't be partitioning by day for such a small dataset,
unless you've onl
Please share us an explain analyze of your query and \d+ of your table
2017-02-20 13:33 GMT+01:00 Job :
> Hu guys,
>
> we have a test machine with Postgresql 9.6.1 an about 800.000.000 record
> in a table.
> Table is partitioned by day, with indexes on partitioned table.
>
> Also a simple query (
Hu guys,
we have a test machine with Postgresql 9.6.1 an about 800.000.000 record in a
table.
Table is partitioned by day, with indexes on partitioned table.
Also a simple query (for example i want to search log occurred in a specific
day), is immediate in tha partitioned table (table_2017_02_1
23 matches
Mail list logo
