On Fri, Apr 29, 2011 at 8:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark gsst...@mit.edu writes:
On Fri, Apr 29, 2011 at 5:45 PM, Christopher Browne cbbro...@gmail.com
wrote:
The bike shedding that I'd rather have would involve enclosing
prompts with /* comments */ so that cut'n'paste
Vlad Arkhipov wrote:
29.04.2011 21:18, Kevin Grittner wrote:
Vlad Arkhipov wrote:
But even if it would work it would not help me anyways. Because
my constraint is much more complex and depends on other tables, I
cannot express it in terms of exclusion constraints.
Are you aware of the
On fre, 2011-04-29 at 19:06 +0100, Greg Stark wrote:
I would second this precise interest. It really annoys me more often
than anything else that when I try to copy/paste an sql query I need
to copy each line one by one. It would be different from MySql but I
think it would be even clearer to
Hello
Actually we had to solve a issue with slow SELECT. The problem was in
low value of JOIN_COLLAPSE_LIMITS. Can we increase a default of this
value. I checked some complex query, and planner needed about 200ms
for JOIN_COLLAPSE_LIMIT = 16. So some around 12 can be well.
Regards
Pavel Stehule
Added to TODO list:
Allow multiple Postgres clusters running on the same machine to
distinguish themselves in the event log
http://archives.postgresql.org/pgsql-hackers/2011-03/msg01297.php
Simon Riggs wrote:
Update docs to say you need fsync to make sync rep work fast.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/6e8e7cc580665ddd43c8ca2acc6d60f345570a57
This patch added this documentation text:
+Replies are only sent when WAL is
Peter Eisentraut pete...@gmx.net writes:
How about just making the continuation prompts empty then?
Personally I'd be very annoyed to lose the %R marker (the are you in
a string literal? flag). So I think that that's not a good default.
Of course, anyone who *is* that concerned about copypaste
Pavel Stehule pavel.steh...@gmail.com writes:
Actually we had to solve a issue with slow SELECT. The problem was in
low value of JOIN_COLLAPSE_LIMITS. Can we increase a default of this
value. I checked some complex query, and planner needed about 200ms
for JOIN_COLLAPSE_LIMIT = 16. So some
Bruce Momjian br...@momjian.us writes:
Simon Riggs wrote:
Update docs to say you need fsync to make sync rep work fast.
Should we also issue a warning message in the server logs for the use of
fsync=off on the standby?
That patch was entirely wrong and has been reverted.
Hi guys,
I have noticed that during VACUUM FULL on reasonably big tables,
replication lag climbs. In order to smooth down the replication lag, I
propose the attached patch which enables vacuum delay for VACUUM FULL.
Please find attached the patch and below more information on this
specific
I thought some more about the bug #5998 business, and I believe there's
still a risk unaddressed by yesterday's patch. Suppose that we begin
a CLUSTER operation on some table, and then while it's running (perhaps
in the sort stage) autovacuum decides to vacuum the table's TOAST table.
The
This is related to the SIREAD lock versus ACCESS EXCLUSIVE lock
thread, but seemed different enough to merit spinning off a new
thread.
Our shop hasn't used large objects so far because of the lack of
security (until 9.1), so I never noticed the rather unusual
transactional semantics of large
On Sat, Apr 30, 2011 at 1:19 PM, Gabriele Bartolini
gabriele.bartol...@2ndquadrant.it wrote:
Hi guys,
I have noticed that during VACUUM FULL on reasonably big tables, replication
lag climbs. In order to smooth down the replication lag, I propose the
attached patch which enables vacuum delay
Robert,
Tom and I were talking about starting maybe June 1, rather than July
1. You seem opposed but I'm not sure why.
Because I think -- strictly based on history and the complexity of the new
features -- we'll still be fixing major issues with the beta in June, which was
what Tom said as
I'll bet someone a fancy drink at a conference that this thread goes to at
least 100 posts.
Let the bikeshedding begin!
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
San Francisco
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Apr 30, 2011, at 9:23 PM, Joshua Berkus j...@agliodbs.com wrote:
Robert,
Tom and I were talking about starting maybe June 1, rather than July
1. You seem opposed but I'm not sure why.
Because I think -- strictly based on history and the complexity of the new
features -- we'll still be
On Apr 30, 2011, at 8:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wonder though if it wouldn't be smarter
to insist that autovacuum acquire some lock on the main table
when processing a toast table.
Boy, it sure seems better to avoid the above if we can. So +1 for the other way
around -
On Apr 30, 2011, at 7:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
Actually we had to solve a issue with slow SELECT. The problem was in
low value of JOIN_COLLAPSE_LIMITS. Can we increase a default of this
value. I checked some complex query, and
Thom Brown t...@linux.com writes:
Excellent! Magnus is a very valuable contributor to the PostgreSQL
community and I think the community can only benefit from this addition to
the core team.
+1
Congrats, Magnus!
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation
Joshua Berkus j...@agliodbs.com writes:
I'll bet someone a fancy drink at a conference that this thread goes to at
least 100 posts.
Of course, if we all are to argue about this bet… :)
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via
Robert Haas robertmh...@gmail.com writes:
I seem to remember that I was the last one to suggest raising these limits
and someone demonstrated rather convincingly that for certain classes of
queries that would cause really big problems.
You proposed removing the collapse limits altogether,
If CF1 is June1, though, when will CF4 be? Having a CF start Dec. 1
is probably a bad idea.
Well, I made a suggestion on this topic in my previous email on the
subject...
I just searched backwards on this thread and I can't find it. There's been a
lot of posts.
--
Josh Berkus
Joshua Berkus j...@agliodbs.com wrote:
I just searched backwards on this thread and I can't find it.
I think he's talking about the bottom of this post:
http://archives.postgresql.org/message-id/BANLkTimnjZNemdpqgK=8Mj=pzq33pz0...@mail.gmail.com
-Kevin
--
Sent via pgsql-hackers mailing
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Joshua Berkus j...@agliodbs.com wrote:
I just searched backwards on this thread and I can't find it.
I think he's talking about the bottom of this post:
--On 30. April 2011 20:19:36 +0200 Gabriele Bartolini
gabriele.bartol...@2ndquadrant.it wrote:
I have noticed that during VACUUM FULL on reasonably big tables, replication
lag climbs. In order to smooth down the replication lag, I propose the
attached patch which enables vacuum delay for
Jaime Casanova ja...@2ndquadrant.com writes:
On Sat, Apr 30, 2011 at 1:19 PM, Gabriele Bartolini
I have noticed that during VACUUM FULL on reasonably big tables, replication
lag climbs. In order to smooth down the replication lag, I propose the
attached patch which enables vacuum delay for
On Sat, Apr 30, 2011 at 9:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
- it would require a query in which
every relation is linked to every other relation by a join clause.
But that *can* happen (remember that clauses generated by transitive
equality do count).
It sounds like you're describing
On 01/05/11 11:53, Greg Stark wrote:
On Sat, Apr 30, 2011 at 9:21 PM, Tom Lanet...@sss.pgh.pa.us wrote:
- it would require a query in which
every relation is linked to every other relation by a join clause.
But that *can* happen (remember that clauses generated by transitive
equality do
On Sat, Apr 30, 2011 at 5:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jaime Casanova ja...@2ndquadrant.com writes:
On Sat, Apr 30, 2011 at 1:19 PM, Gabriele Bartolini
I have noticed that during VACUUM FULL on reasonably big tables, replication
lag climbs. In order to smooth down the replication
Hi,
I've been digging in the sources, and I've noticed the MaxOffsetNumber
is defined (in storage/off.h) like this
(BLCKSZ / sizeof(ItemIdData))
I guess it might be made a bit more precise by subtracting the header
like this
(BLCKSZ - offsetof(PageHeaderData, pd_linp) / sizeof(ItemIdData))
Hi,
when working on the integrity checking tool, I've noticed there are a
bit trange tuples in the btree indexes. E.g. if I do this:
create table test_table (id int);
insert into test_table select i from generate_series(1,1000) s(i);
create index test_index on test_table(id);
then pageinspect
Mark Kirkwood mark.kirkw...@catalyst.net.nz writes:
On 01/05/11 11:53, Greg Stark wrote:
On Sat, Apr 30, 2011 at 9:21 PM, Tom Lanet...@sss.pgh.pa.us wrote:
- it would require a query in which
every relation is linked to every other relation by a join clause.
But that *can* happen (remember
Tomas Vondra t...@fuzzy.cz writes:
testdb=# select bt_page_items('test_index', 3);
bt_page_items
--
(1,(1,1),8,f,f,)
(2,(2,1),12,f,f,ca 01 00 00)
(3,(4,1),12,f,f,93 03 00 00)
(3 rows)
I don't understand the first row and I've been unable to
Hello
a slow query is just simple
like
SELECT FROM a
LEFT JOIN b ON ..
LEFT JOIN c ON ..
LEFT JOIN d ON ..
LEFT JOIN e ON ..
WHERE e.x = number
a slow query plan
explain analyze select * from v_vypis_parcel_puvodni where par_id = 1396907206
---
34 matches
Mail list logo
