Added to TODO:
* Consider sorting entries before inserting into btree index
http://archives.postgresql.org/pgsql-general/2008-01/msg01010.php
---
Tom Lane wrote:
> Clodoaldo <[EMAIL PROTECTED]> writes:
> > 2008/1/16, To
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> A random thought: Is there not some way of representing this difference
> in the planner?
It's not so much that we have no way to represent the ordering, as that
the planner currently doesn't have any place in its conceptual model for
costs incu
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> In the long run, for queries inserting many rows it might be interesting
>> to accumulate all the entries intended for a btree index and sort them
>> before inserting. Not sure about possible downsides of that.
> Yeah, in the long
Russell Smith <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> A possibly usable workaround for now is "set enable_hashagg = off"
>> to force a GroupAggregate plan, which will deliver the values sorted
>> by (data, usuario) rather than by their hash values.
> If you add ORDER BY to the query, do y
Tom Lane escribió:
> In the long run, for queries inserting many rows it might be interesting
> to accumulate all the entries intended for a btree index and sort them
> before inserting. Not sure about possible downsides of that.
Yeah, in the long run we need a more flexible approach towards ind
On Jan 20, 2008 6:44 AM, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 20, 2008 at 09:29:16AM -0200, Clodoaldo wrote:
> > Will "enable_hashagg" be settable(*) per query or only at server
> > start/reload?
>
> The enable_* settings are per session, so you can disable hashagg just
On Sun, Jan 20, 2008 at 09:29:16AM -0200, Clodoaldo wrote:
> Will "enable_hashagg" be settable(*) per query or only at server start/reload?
The enable_* settings are per session, so you can disable hashagg just
before the query and reenable it just after, or disable it for just
that process/user/d
2008/1/20, Tom Lane <[EMAIL PROTECTED]>:
> Clodoaldo <[EMAIL PROTECTED]> writes:
> > 2008/1/16, Tom Lane <[EMAIL PROTECTED]>:
> >> I don't know of any reason to think that insertion is slower in 8.3
> >> than it was in 8.2, and no one else has reported anything of the sort.
>
> > The old server rep
On Sat, Jan 19, 2008 at 10:33:00PM -0500, Tom Lane wrote:
> The difference comes from the fact that the HashAggregate step --- which
> is being done on hashing columns (data, usuario) --- is effectively
> reading out in hash-value order for usuario, meaning that that is the
> order in which we make
Tom Lane wrote:
Clodoaldo <[EMAIL PROTECTED]> writes:
2008/1/16, Tom Lane <[EMAIL PROTECTED]>:
I don't know of any reason to think that insertion is slower in 8.3
than it was in 8.2, and no one else has reported anything of the sort.
The old server reproduces the behavior o
Clodoaldo <[EMAIL PROTECTED]> writes:
> 2008/1/16, Tom Lane <[EMAIL PROTECTED]>:
>> I don't know of any reason to think that insertion is slower in 8.3
>> than it was in 8.2, and no one else has reported anything of the sort.
> The old server reproduces the behavior of the new one.
Okay, Clodoald
Clodoaldo <[EMAIL PROTECTED]> writes:
> The old server reproduces the behavior of the new one.
Well, that's just weird. Let's see, FC6 has oprofile --- maybe oprofile
measurements on 8.2 and 8.3 on the same box would tell something.
Do you know how to use that? Alternatively, if you could give m
2008/1/16, Tom Lane <[EMAIL PROTECTED]>:
> I went through this thread again, and noticed something that no one
> seems to have remarked on at the time: the vmstat numbers near the
> bottom of this post
>
> http://archives.postgresql.org/pgsql-general/2008-01/msg00161.php
>
> show close to 100% I/O
2008/1/16, Tom Lane <[EMAIL PROTECTED]>:
> I went through this thread again, and noticed something that no one
> seems to have remarked on at the time: the vmstat numbers near the
> bottom of this post
>
> http://archives.postgresql.org/pgsql-general/2008-01/msg00161.php
This post is from january
2008/1/16, Joshua D. Drake <[EMAIL PROTECTED]>:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Wed, 16 Jan 2008 00:29:16 -0500
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > > If we are sure that this issue is apparent actual row insertion it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 16 Jan 2008 00:29:16 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > If we are sure that this issue is apparent actual row insertion it
> > should be easy to duplicate.
>
> I think you missed my
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> If we are sure that this issue is apparent actual row insertion it
> should be easy to duplicate.
I think you missed my point entirely: I believe it's specific to
Clodoaldo's installation. Certainly I didn't have any luck reproducing
a huge 8.2-to-
Tom Lane wrote:
I went through this thread again, and noticed something that no one
seems to have remarked on at the time: the vmstat numbers near the
bottom of this post
http://archives.postgresql.org/pgsql-general/2008-01/msg00161.php
show close to 100% I/O wait time (either that or 50% idle
I went through this thread again, and noticed something that no one
seems to have remarked on at the time: the vmstat numbers near the
bottom of this post
http://archives.postgresql.org/pgsql-general/2008-01/msg00161.php
show close to 100% I/O wait time (either that or 50% idle 50% I/O wait,
whic
2008/1/15, Alvaro Herrera <[EMAIL PROTECTED]>:
> Clodoaldo escribió:
>
> > I guess the samples above are not very useful. If you think it would
> > help, i can upload the database dump, along with the source txt files
> > and the insert script, to some web directory, so you can see it
> > working.
Clodoaldo escribió:
> I guess the samples above are not very useful. If you think it would
> help, i can upload the database dump, along with the source txt files
> and the insert script, to some web directory, so you can see it
> working. Its bziped size is 914MB so I will only upload it if you s
2008/1/11, Clodoaldo <[EMAIL PROTECTED]>:
> 2008/1/10, Clodoaldo <[EMAIL PROTECTED]>:
> > 2008/1/10, Tom Lane <[EMAIL PROTECTED]>:
> > > It would be interesting to see the identical test on Clodaldo's
> > > installations.
> >
> > This is 8.2.6 in the new server:
> >
> > cpn=> create table foo (f1 i
2008/1/10, Clodoaldo <[EMAIL PROTECTED]>:
> 2008/1/10, Tom Lane <[EMAIL PROTECTED]>:
> > It would be interesting to see the identical test on Clodaldo's
> > installations.
>
> This is 8.2.6 in the new server:
>
> cpn=> create table foo (f1 int, f2 int, f3 int, f4 real);
> CREATE TABLE
> cpn=> creat
2008/1/10, Tom Lane <[EMAIL PROTECTED]>:
> "Scott Marlowe" <[EMAIL PROTECTED]> writes:
> > OK, I was looking at the previous thread that you thought had
> > disappeared, and with the explain analyze output from 8.3 I noticed
> > something odd.
>
> > For 8.2 you had something like this:
>
> >
On Thu, 10 Jan 2008, Alvaro Herrera wrote:
Do tell, what's your wal_buffers setting? Have you tried increasing
that?
Original post here suggested wal_buffers=512kb in 8.2 and 1024kb in the
8.3 config. Seemed plenty big for this scale of server.
--
* Greg Smith [EMAIL PROTECTED] http://www
Clodoaldo escribió:
> If you read that thread you will notice my experience with
> xlog_seg_size of 1GB which makes the time goes down to 1,300 sec,
> still much more than 8.2.
Do tell, what's your wal_buffers setting? Have you tried increasing
that?
--
Alvaro Herrera
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> OK, I was looking at the previous thread that you thought had
> disappeared, and with the explain analyze output from 8.3 I noticed
> something odd.
> For 8.2 you had something like this:
> QUERY PLAN
> --
2008/1/10, Scott Marlowe <[EMAIL PROTECTED]>:
> On Jan 10, 2008 9:50 AM, Clodoaldo <[EMAIL PROTECTED]> wrote:
>
> > I have seen performance degradation at every new version since 7.3.
> > But now 8.3 is a complete disaster. It could be that my most expensive
> > query is just a corner case, but I d
On Jan 10, 2008 9:50 AM, Clodoaldo <[EMAIL PROTECTED]> wrote:
> I have seen performance degradation at every new version since 7.3.
> But now 8.3 is a complete disaster. It could be that my most expensive
> query is just a corner case, but I don't believe it. I posted about it
> but the whole thre
29 matches
Mail list logo
