Sergey Burladyan writes:
> 1. create master
> 2. create standby from it
> 3. create unlogged table and hash index like:
> create unlogged table test (id int primary key, v text);
> create index on test using hash (id);
> 3. stop master
> 4. promote standby
>
> now,
gt; you or someone has some solution to this problem.
> As far as I know this is the only remaining open issue. Sergey, please
> verify. I appreciate the work everyone has done to improve this, and
> all the existing fixes have been pushed to all supported branches. :-)
Yes, than
Bruce Momjian writes:
> On Tue, Jun 20, 2017 at 06:42:58PM +0300, Sergey Burladyan wrote:
> > If file at standby in old data directory is different from same file at
> > master, but it have same size, it will be hardlinked into new data
> > directory at standby and does n
/main/pg_xlog/ | awk '/4ED0A00AE/,/xxx/ { print
}' | wc -l
2456
===
See https://www.postgresql.org/docs/9.2/static/wal-configuration.html
> they are recycled (renamed to become the next segments in the numbered
> sequence)
--
Sergey Burladyan
--
Sent v
Bruce Momjian writes:
> On Tue, Jun 20, 2017 at 01:10:26PM +0300, Sergey Burladyan wrote:
> > Bruce Momjian writes:
> > > > Uh, as I understand it the rsync is going to copy the missing WAL file
> > > > from the new master to the standby, right, and I think
Amit Kapila writes:
> On Tue, Jun 20, 2017 at 3:40 PM, Sergey Burladyan wrote:
> > Bruce Momjian writes:
> >
> >> On Mon, Jun 19, 2017 at 10:59:19PM -0400, Bruce Momjian wrote:
> >> > On Tue, Jun 20, 2017 at 03:50:29AM +0300, Sergey Burladyan wrote:
> &
Bruce Momjian writes:
> On Mon, Jun 19, 2017 at 10:59:19PM -0400, Bruce Momjian wrote:
> > On Tue, Jun 20, 2017 at 03:50:29AM +0300, Sergey Burladyan wrote:
> > > 20 июн. 2017 г. 1:21 пользователь "Bruce Momjian"
> > > написал:
> > >
> >
20 июн. 2017 г. 1:21 пользователь "Bruce Momjian"
написал:
We are saying that Log-Shipping should match "Latest checkpoint
location", but the WAL for that will not be sent to the standby, so it
will not match, but that is OK since the only thing in the non-shipped
WAL file is the checkpoint reco
Bruce Momjian writes:
> On Fri, Jun 16, 2017 at 04:33:16AM +0300, Sergey Burladyan wrote:
> > Bruce Momjian writes:
> > > !
> > > ! Also, if upgrading standby servers, change wal_level
> > > ! to replica in the postgresql.conf
Bruce Momjian writes:
> On Fri, Jun 16, 2017 at 08:10:13PM +0530, Amit Kapila wrote:
> > On Fri, Jun 16, 2017 at 7:03 AM, Sergey Burladyan
> > wrote:
> > > Bruce Momjian writes:
> > >
> > >> ! against the old primary and standby clusters. Ve
: shut down
pg_control last modified: Fri Jun 16 03:57:22 2017
Latest checkpoint location: 0/D28
Prior checkpoint location:0/1604878
Latest checkpoint's REDO location:0/D28
Latest checkpoint's REDO WAL file: 0001
Vladimir Borodin writes:
> > 6 июня 2017 г., в 23:30, Sergey Burladyan написал(а):
> >
> > Dmitriy Sarafannikov writes:
> >
> >> Starting and stopping master after running pg_upgrade but before rsync to
> >> collect statistics
> >> was a b
rade.html
> f. Start and stop the new master cluster
> In the new master cluster, change wal_level to replica in the postgresql.conf
> file and then start and stop the cluster.
and there is no any suggestion to disable autovacuum for it.
--
Sergey Burladyan
--
Sent via pgsql-hackers m
8] checkpoint: redo 0/1220; tli 1; nextxid 1267; nextoid
16393; nextmulti 1; nextoffset 0; shutdown at 2017-06-01 16:09:32 MSK
ReadRecord: record with zero len at 0/1280
This WAL file is only at master pg_xlog, and not in WAL archive.
And my second question, this algorithm with rsync
Thank you, Alexander!
This is definitely the example we are looking for!
Hat tip to Dmitry especially for this commit
https://github.com/akorotkov/pgsphere/commit/971d2c5d61f17774a6d8d137ca3ad87e2883048f
Regards,
Sergey Mirvoda
On Tue, Apr 11, 2017 at 2:17 PM, Alexander Korotkov <
a.ko
About view.
I found where I saw it was a discussion solve some problems with view
https://wiki.postgresql.org/wiki/Todo#Views_and_Rules, ie it is in the list
of TODO, so there is a chance that it will be implemented.
03 Май 2015 г. 12:15 пользователь "Sergey Grinko"
написал:
>
.
I hope that the PostgreSQL developers still implement the storage of the
full DDL and PostgreSQL then receive another plus in competition with
commercial databases.
01 Май 2015 г. 23:03 пользователь "Jim Nasby"
написал:
> On 4/30/15 6:44 AM, Sergey Grinko wrote:
>
>> Now
I agree that it is better to show what really works.
I propose to allow additional option through a source code which is made on
the basis of a compilation of metadata.
This will solve the problem.
2015-04-30 16:19 GMT+03:00 Pavel Stehule :
>
>
> 2015-04-30 15:08 GMT+02:00 Serg
of the definition to
CREATE END; unchanged.
--
Yours faithfully, Sergey Grinko
Email: sergey.gri...@gmail.com
es don't have pg_receivexlog) and can quite easily be worked
> around by creating the archive_status directory.
The workaround works perfectly for me in this case, I'm going to
updrade it up to 9.4 anyway soon.
Thank you, Andres.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant
ome extra info or debugging.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (499) 346-7196, +7 (988) 888-1979
gray...@gmail.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
archive_status/000402B60019.done":
No such file or directory
pg_receivexlog: disconnected..
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (499) 346-7196, +7 (988) 888-1979
gray...@gmail.com
--
Sent via pg
; Dang. Stupid typo. And my tests didn't catch it, because I had
>> > archive_directory in the target directory :(
I started getting these errors after upgrading from 9.2.8 to 9.2.10.
Is it something critical that requires version downgrade or I can just
ignore that errors?
--
Kind regards,
Sergey
On Tue, Sep 2, 2014 at 7:59 PM, Bruce Momjian wrote:
> On Wed, Apr 23, 2014 at 12:41:41PM -0700, Sergey Konoplev wrote:
>> On Wed, Apr 23, 2014 at 5:26 AM, Bruce Momjian wrote:
>> > Sergey, are you seeing a problem only because you are
>> > interacting with other syst
So what's wrong with the patch?
And what should I change in it for 9.5?
2014-07-07 3:12 GMT+04:00 Greg Stark :
> On Sun, Jul 6, 2014 at 8:40 AM, Sergey Muraviov
> wrote:
> > Is there anyone who can commit the patch?
>
> So what I'm inclined to do here (sigh) is com
Hi.
Is there anyone who can commit the patch?
2014-06-25 20:17 GMT+04:00 Pavel Stehule :
>
>
>
> 2014-06-24 19:45 GMT+02:00 Sergey Muraviov :
>
> Hi.
>>
>> Is there any problem with the patch?
>>
>
> I tested it and I had not any issue with last ver
the changes to
> 9.5 and that gives us more time to be sure we're ok with them.
>
>
> --
> greg
>
--
Best regards,
Sergey Muraviov
t; Probably, we need to define a domain by ourselves for regression test to
> ensure
> the test stability, not using the system "unconfined" domain that has
> different
> meaning by release.
>
> I'll make a patch. Please wait for a while.
>
> Thanks for your test &a
Hi.
Here's a patch that fixes it.
--
Best regards,
Sergey Muraviov
diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
index cabfbdd..0b6f383 100644
--- a/doc/src/sgml/release-9.4.sgml
+++ b/doc/src/sgml/release-9.4.sgml
@@ -1587,7 +1587,7 @@
Please check this patch.
2014-05-12 22:56 GMT+04:00 Sergey Muraviov :
> Hi.
>
> I'll try to fix it tomorrow.
>
>
> 2014-05-12 18:42 GMT+04:00 Tom Lane :
>
> Greg Stark writes:
>> > On Mon, May 12, 2014 at 2:12 PM, Greg Stark wrote:
>> >> Hm, t
's no way to
> > indicate wrapping versus newlines.
>
> Barring anyone complaining that the format changed, I'd say the issue
> is not that you added them but that the accounting for line length
> fails to include them.
>
> regards, tom lane
>
--
Best regards,
Sergey Muraviov
rebased
2014-04-29 7:43 GMT+04:00 Michael Paquier :
> On Tue, Apr 29, 2014 at 12:37 PM, Sergey Muraviov
> wrote:
> > 2014-04-29 5:52 GMT+04:00 Peter Eisentraut :
> >
> >> Please fix this compiler warning. I think it came from this patch.
> >> print.c:
On Wed, Apr 23, 2014 at 5:26 AM, Bruce Momjian wrote:
> Sergey, are you seeing a problem only because you are
> interacting with other systems that didn't reset their epoch?
I faced this after upgrading clusters with PgQ Skytools3 installed
only. They didn't interact with a
On Tue, Apr 22, 2014 at 8:08 PM, Sergey Burladyan wrote:
> On Wed, Apr 23, 2014 at 6:38 AM, Sergey Konoplev wrote:
>> BTW, I didn't manage to make a test case yet. Recently, when I was
>> migrating several servers to skytools3 and upgrading from 9.0 to 9.2,
>> I not
On Wed, Apr 23, 2014 at 6:38 AM, Sergey Konoplev wrote:
>
> BTW, I didn't manage to make a test case yet. Recently, when I was
> migrating several servers to skytools3 and upgrading from 9.0 to 9.2,
> I noticed that epoch was copied, timeline id was >0 after upgrade, but
&g
On Tue, Apr 22, 2014 at 6:33 PM, Sergey Burladyan wrote:
> Current pg_upgrade copy XID into new cluster, but not it epoch. Why?
>
> Without epoch from old cluster txid_current() in upgraded database return
> lower value than before upgrade. This break, for example, PgQ and it must
&
://lists.pgfoundry.org/pipermail/skytools-users/2014-April/001812.html
--
Sergey Burladyan
There were no support for wrapping and old-ascii line style in expanded
mode at all.
But now they are.
2014-04-11 21:58 GMT+04:00 Alvaro Herrera :
> Sergey Muraviov wrote:
> > I hope that I realized old-ascii logic correctly.
>
> I don't know what you changed here, but I do
|
> | : |
> | xx : |
> | x : |
> | xx : |
> | xx |
> | xx |
> | xxx
Hi.
I've done some corrections for printing "newline" and "wrap" indicators.
Please review the attached patch.
2014-04-11 0:14 GMT+04:00 Sergey Muraviov :
> Hi.
>
> Thanks for your tests.
>
> I've fixed problem with headers, but got new o
The header and data
> need to be stepped through in parallel rather than having a loop to
> handle the wrapping within the handling of a single line. I don't
> really have time for that today but if you can get to it that would be
> fine,
>
--
Best regards,
Sergey Muraviov
pg_regress?
>
> There's a pset variable to set the target width so at least the
> formatting code can be tested. It would be nice to have the ioctl at
> least get called on the regression farm so we're sure we aren't doing
> something unportable.
>
> --
> greg
>
--
Best regards,
Sergey Muraviov
ny postgres related indexable Hamming/Manhattan distance
experiments/thoughts/discussions, if kNN can be used here or not,
because from my understanding it can be represented as spatial (I
might be very wrong here).
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.
On Thu, Mar 27, 2014 at 3:26 PM, Sergey Konoplev wrote:
> On Sun, Sep 22, 2013 at 4:38 PM, Stas Kelvich wrote:
>> Here is the patch that introduces kNN search for cubes with euclidean,
>> taxicab and chebyshev distances.
>
> What is the status of this patch?
Ref
Hi everyone,
On Sun, Sep 22, 2013 at 4:38 PM, Stas Kelvich wrote:
> Here is the patch that introduces kNN search for cubes with euclidean,
> taxicab and chebyshev distances.
What is the status of this patch?
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
shed to repo.
--
Sergey Burladyan
Alex Hunsaker writes:
> On Tue, Feb 25, 2014 at 6:56 AM, Sergey Burladyan wrote:
>
> > It looks like I found the problem, Perl use reference count and something
> > that
> > is called "Mortal" for memory management. As I understand it, mortal is
> &
Hello, All!
eshkin...@gmail.com writes:
> create function perl_test(IN data text, OUT v1 text, OUT v2 integer, OUT v3
> integer, OUT v4 json, OUT v5 json)
> returns record as
> $BODY$
>
> use strict;
> use warnings;
>
> my $res->{'v1'} = 'content';
>
> return $res;
>
> $BODY$
> language plper
Thanks.
2014-02-17 12:22 GMT+04:00 Emre Hasegeli :
> 2014-02-16 18:37, Sergey Muraviov :
>
> > New code doesn't work with empty strings but I've done minor optimization
> > for this case.
>
> It seems better now. I added some new lines and spaces, removed unnec
Hi.
Thanks for your review.
2014-02-15 20:08 GMT+04:00 Emre Hasegeli :
> Hi,
>
> This is my review about 3th version of the patch. It is an useful
> improvement in my opinion. It worked well on my environment.
>
> 2013-12-11 17:43:06, Sergey Muraviov :
> > It works in e
Hi.
Now it looks fine for me.
2014-01-28 Dimitri Fontaine :
> Hi,
>
> Sergey Muraviov writes:
> > Now patch applies cleanly and works. :-)
>
> Cool ;-)
>
> > But I have some notes:
> >
> > 1. There is an odd underscore character in functi
tion of the required version of the extension.
So we can use different versions of extensions in different databases.
PS
Sorry for my English.
2014/1/24 Fabrízio de Royes Mello
>
> On Fri, Jan 24, 2014 at 6:57 AM, Dimitri Fontaine
> wrote:
> >
> > Sergey Muraviov writes:
>
rg)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
--
Best regards,
Sergey Muraviov
ell:
>
>
> http://www.postgresql.org/message-id/flat/CAL_0b1s4QCkFy_55kk_8XWcJPs7wsgVWf8vn4=jxe6v4r7h...@mail.gmail.com
This problem worries me a lot too. If someone is interested I still
have a file system copy of the buggy cluster including WAL.
--
Kind regards,
Sergey Konop
On Mon, Dec 30, 2013 at 2:03 AM, knizhnik wrote:
> On 12/30/2013 01:22 AM, Sergey Konoplev wrote:
>> On Sun, Dec 29, 2013 at 8:44 AM, knizhnik wrote:
>>> But passing direved_table type instead of base_table type to volume()
>>> function for record belonging to derived
unction volume(r base_table) returns integer as $$ begin
return r.x*r.y;
end; $$ language plpgsql strict stable;
create function volume(r derived_table) returns integer as $$ begin
return volume(r::base_table) *r.z;
end; $$ language plpgsql strict stable;
--
Kind regards,
Sergey Konoplev
Postgre
rint.c:2263: trailing whitespace.
>
>
--
Best regards,
Sergey Muraviov
From be9f01777599dc5e84c417e5cae56459677a88d4 Mon Sep 17 00:00:00 2001
From: Sergey Muraviov
Date: Wed, 11 Dec 2013 20:17:26 +0400
Subject: [PATCH 1/2] wrapped tables in expanded mode
---
# semodule -l | grep sepgslq
sepgsql-regtest 1.07
Full list of modules is in attachment.
2013/12/18 Kohei KaiGai
> Could you show me semodule -l on your environment?
> I believe security policy has not been changed between F19 and F20...
>
> Thanks,
>
> 2013/12/18 Sergey
Hi
I've tried to test postgres 9.3.2 and 9.4devel with selinux on Fedora 20
and met with a label regression test failure.
PS
I've got some warning during build process.
--
Best regards,
Sergey Muraviov
regression.out
Description: Binary data
regression.diffs
Description: B
Hello
2013/12/18 Sameer Thakur
> On Wed, Dec 11, 2013 at 11:13 PM, Sergey Muraviov
> wrote:
> > Hi.
> >
> > I've improved the patch.
> > It works in expanded mode when either format option is set to wrapped
> (\pset
> > format wrapped), or we hav
dfsadf asdf sad f sadf sad fadsf |
+-[ RECORD 2 ]-+
| value | afadsafasd fasdf asdfasd |
+---+------+
Regards,
Sergey
2013/12/10 Jeff Janes
> On Mon, Dec 2, 2013 at 10:45 P
istribution dependend and
statistic dependent.
Cheers,
Sergey
PS I'm not a statistician, but I use statistics a lot
*******
Sergey E. Koposov, PhD, Research Associate
Institute of Astronomy, University of Cambridge
Madingle
-
> afadsafasd fasdf asdfasd fsad fas df sadf sad f sadf sadf sa df
> sadfsadfasd fsad fsa df sadf asd fa sfd sadfsadf a.
> .sdf sad f sadf sad fadsf
> (1 row)
>
> It works as expected
>
> but it is not supported for row view
Pavel Stehule
> Hello
>
> do you know a pager less trick
>
> http://merlinmoncure.blogspot.cz/2007/10/better-psql-with-less.html
>
> Regards
>
> Pavel Stehule
>
>
> 2013/12/3 Sergey Muraviov
>
>> Hi.
>>
>> Psql definitely have a problem with
0.00472627}
|
| histogram_bounds |
|
| correlation| 1
|
| most_common_elems |
|
| most_common_elem_freqs |
|
| elem_count_histogram |
|
+-[ RECORD 3
]---+-+
Best regards,
Sergey Mur
/www.postgresql.org/mailpref/pgsql-hackers
>
Hello!
Is it possible to fix my surname in changelog?
-Sergey Burladyn
+Sergey Burladyan
it is not a problem if it is impossible :-)
Thanks!
--
Sergey Burladyan
On Wed, Oct 30, 2013 at 12:51 PM, Sergey Konoplev wrote:
> On Wed, Oct 30, 2013 at 12:17 PM, Alvaro Herrera
> wrote:
>>> > I wasn't talking about a built-in support. It was about an ability (a
>>> > way) to back sh_buf with hugepages.
&
are several articles in the web describing how to do this,
except the mine one. And the win becomes mostly significant when you
have 64GB and more on your server.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-
I found this parameter in the docs nor it works when I specify
it in postgresql.conf.
LOG: unrecognized configuration parameter
"dynamic_shared_memory_type" in file
"/etc/postgresql/9.3/main/postgresql.conf" line 114
FATAL: configuration file "/etc/postgresql/9.3/main/postgr
On Wed, Oct 30, 2013 at 8:11 AM, Tom Lane wrote:
> Sergey Konoplev writes:
>> On Tue, Oct 29, 2013 at 9:31 PM, Tom Lane wrote:
>>> Say what? There's never been any hugepages support in Postgres.
>
>> There were an ability to back shared memory with hugepages
On Tue, Oct 29, 2013 at 9:31 PM, Tom Lane wrote:
> Sergey Konoplev writes:
>> On Wed, Oct 23, 2013 at 11:03 PM, Abhijit Menon-Sen
>> wrote:
>>> This is a slightly reworked version of the patch submitted by Richard
>>> Poole last month, which was based o
f
9.3? IMHO hugepages is a very important ability that postgres lost in
9.3, and it would be great to have it back ASAP.
Thank you.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray...@gmail.com
ed: Why should we do this here? In what way is
> pgstattuple like or not like the other things that are in core?
I would highlight it as it became a kind of routine one. Also,
sometimes it is required to solve problems, not to make new features,
so it often can not wait.
--
Kind regards,
Se
not the only person
who faced these nuances.
According to this I would like to know if it is possible to move
pgstattuple to core? And if it is I would like to request this
feature.
Thank you.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1
On Wed, Sep 18, 2013 at 2:06 AM, Andres Freund wrote:
> On 2013-09-17 23:12:24 -0700, Sergey Konoplev wrote:
>> How safe is it to use the technique described by the link below with
>> system catalog tables to remove bloat?
>> (in a couple of words it is about moving tuple
-longexclusive-locks/
Are there any caveats?
Thank you.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray...@gmail.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
uncate will be a non-issue.
Well, according to the pgstattuple log OP showed, free percent jumps
from 1.82 to 70.07 in one minute, so I suppose an empty tail is
inevitable anyway, so there should be locks to truncate by vacuum, if
I understand things correct.
--
Kind regards,
Sergey Konoplev
Postg
is issue.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray...@gmail.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
ne day?
Do you have some processes that intensively create tables or columns
and then delete them or create them in transaction and rollback the
transaction?
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 8
830040 | 0.11 | 1459439 |
> 204321460 | 3.21 | 5939017376 | 93.32
> (1 row)
I guess you need to VACUUM FULL pg_attribute, if it is possible in
your situation of course. If it is not, let me know, I have another
one tricky way of solving this problem in my mind.
--
Kin
.2/interactive/pgstattuple.html
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
Profile: http://www.linkedin.com/in/grayhemp
Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979
Skype: gray-hemp
Jabber: gray...@gmail.com
--
Sent via pgsql-hackers mailing list (p
ther full dump/restore or schema only dump/restore plus trigger
based replication (londiste, slony) to migrate data.
--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA
Profile: http://www.linkedin.com/in/grayhemp
Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-197
37)
> is of segment 0001000E00A7.
>
> Wonder if whatever configuration he is using is sub-optimal that these
> many WAL segments can be re-cycled upon a checkpoint? Or is this okay?
Is archive_mode=on?
What is archive_command?
Is the server in the recovery mode?
--
Kind regards,
Sergey
s
>
> --
> looking forward
> thanks
>>
> Mikhail
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Kind regards,
Sergey Konoplev
Da
p .history file :-) Then I
just copy needed WALs from archive into pg_xlog and remove recovery.conf.
It seems that we're missing a setting, something like recovery_target =
> 'immediate', which would mean "stop as soon as consistency is reached". Or
> am I missing some trick?
>
This will be helpful :)
--
Sergey Burladyan
you think that buildfarm
with icc 11.1 -O1 carry more information than say running gcc, i can
still run icc.
S
*****
Sergey E. Koposov, PhD, Research Associate
Institute of Astronomy, University of Cambridge
Madingley road, CB3 0HA, Cambrid
unless somebody suggest otherwise, i'm going to switch to gcc on this
buildfarm.
Cheers,
Sergey
*****
Sergey E. Koposov, PhD, Research Associate
Institute of Astronomy, University of Cambridge
Madingley road, CB3 0HA, Cambridge, UK
T
have a similar ICC version (dugong's says it is 10.0 20070809)
to try? Also, Sergey, can you find a non-dot-zero release to try?
I think it is indeed the main issue.
I've tried 10.1 ( 10.1.011 ) and it doesn't fail.
When I tried 11.1 (icc (ICC) 11.1 20100401 ) it failed in a q
-15 23:06:19 MSK [50f5a8ab.1175:57] ERROR: tablespace "testspace" is
not empty
2013-01-15 23:06:19 MSK [50f5a8ab.1175:58] STATEMENT: DROP TABLESPACE
testspace;
2013-01-15 23:06:19 MSK [50f5a8aa.1162:12] DEBUG: server process (PID 4469)
exited with exit code 0
Cheers,
S
**
S
PS I wouldn't be surprised that it is a compiler bug though. But I did see the
failure with newer icc as well.
*
Sergey E. Koposov, PhD, Research Associate
Institute of Astronomy, University of Cambridge
Madingley road, CB3 0HA,
ng list (pgsql-gene...@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>
> --
> Bruce Momjian http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + It&#
On Sun, 2 Sep 2012, Peter Geoghegan wrote:
On 2 September 2012 16:26, Sergey Koposov wrote:
That's why we support altering that value with an ALTER TABLE...ALTER
COLUMN DDL statement. You might at least consider increasing the
statistics target for the column first though, to see if that
On Sun, 2 Sep 2012, Tom Lane wrote:
Sergey Koposov writes:
The problem is definitely the misestimation here:
-> Index Scan using data_objid_idx on data d1 (cost=0.00..26603.32
rows=415080 width=40) (actual time=0.010..0.050 rows=248 loops=11456)
Index Cond: (ob
Thanks for your comments.
On Sun, 2 Sep 2012, Peter Geoghegan wrote:
On 2 September 2012 06:21, Sergey Koposov wrote:
I think that this kind of question is better suited to the
pgsql-performance list. Granted, it was presented as a bug report
(though they're generally sent to -bugs rather
, and afaik the estimation of the
number of rows is known to be incorrect, in the case of column
correlation.
Third, according at least to my understanding in the fully cached regime
bitmap scan should not take two orders of magnitude more CPU time than
index scan.
Sergey
Regard
Pavel St
th ~ 20e9 rows. My feeling is that the bitmap index scan code
is somehow unprepared to combine two bitmaps for such a big table, and this
leads to the terrible performance.
Regards,
Sergey
PS Here are the schemas of the tables, just in case:
wsdb=> \d test
Table "
On Thu, 7 Jun 2012, Tom Lane wrote:
I extended the patch to also cover DropDatabaseBuffers,
FlushRelationBuffers, and FlushDatabaseBuffers, which have got the exact
same type of full-pool scan loop, and committed it.
Thanks everybody for the patches/commits.
Sergey
seems like it should be worthwhile.
How do we go about getting reasonable proof that it is safe?
That's enough for me.
So is it planned to apply that patch for 9.2 ?
Thanks,
S
*****
Sergey E. Koposov, PhD, Research Associate
In
*
Sergey E. Koposov, PhD, Research Associate
Institute of Astronomy, University of Cambridge
Madingley road, CB3 0HA, Cambridge, UK
Tel: +44-1223-337-551 Web: http://www.ast.cam.ac.uk/~koposov/
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Wed, 6 Jun 2012, Ants Aasma wrote:
On Wed, Jun 6, 2012 at 2:27 PM, Sergey Koposov wrote:
I've quickly tested your lockfree-getbuffer.patch patch with the test case
you provided and I barely see any improvement (2% at max)
https://docs.google.com/open?id=0B7koR68V2nM1QVBxWGpZdW4wd0U
t
1 - 100 of 261 matches
Mail list logo
