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
---
Tomas Vondra 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
Mark Kirkwood writes:
> On 01/05/11 11:53, Greg Stark wrote:
>> On Sat, Apr 30, 2011 at 9:21 PM, Tom Lane 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
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 re
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))
On Sat, Apr 30, 2011 at 5:48 PM, Tom Lane wrote:
> Jaime Casanova 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
On 01/05/11 11:53, Greg Stark wrote:
On Sat, Apr 30, 2011 at 9:21 PM, Tom Lane 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 y
On Sat, Apr 30, 2011 at 9:21 PM, Tom Lane 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 precisely a "st
Jaime Casanova 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 VACUUM FULL.
> AF
--On 30. April 2011 20:19:36 +0200 Gabriele Bartolini
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 VACUUM FULL.
Hmm, but this will mo
"Kevin Grittner" writes:
> Joshua Berkus 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
... which was:
CF #1: J
Joshua Berkus 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 list (pgsql-hacke
> > 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
P
Robert Haas 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, but that crashed
and
Joshua Berkus 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 pgsql-hackers mai
Thom Brown 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 et Support
On Apr 30, 2011, at 7:38 PM, Tom Lane wrote:
> Pavel Stehule 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_
On Apr 30, 2011, at 8:22 PM, Tom Lane 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 - make CLUSTER lock t
On Apr 30, 2011, at 9:23 PM, Joshua Berkus 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 fixing m
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 subsc
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
On Sat, Apr 30, 2011 at 1:19 PM, Gabriele Bartolini
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 for VACUUM FULL.
>
AFAICS, th
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 o
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 autovacu
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
Bruce Momjian 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.
regards
Pavel Stehule 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 around 12 can be well.
Peter Eisentraut 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 copy&paste cases can
se
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
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
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
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
> 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 yo
On Fri, Apr 29, 2011 at 8:11 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Fri, Apr 29, 2011 at 5:45 PM, Christopher Browne
>> wrote:
>>> The "bike shedding" that I'd rather have would involve enclosing
>>> prompts with /* comments */ so that cut'n'paste could be expected to
>>> generate outpu
34 matches
Mail list logo
