Prev: [HACKERS] Functional dependencies and GROUP BY
Next: [HACKERS] How to get permission to debug postgres?
From: Peter Eisentraut on 18 Jul 2010 04:40
On lör, 2010-07-17 at 11:13 -0600, Alex Hunsaker wrote:
> its really no surprise that your test with 1600 columns had little
> effect. As it loops over the the indexes, then the index keys and
> then the group by items right? So I would expect the more indexes you
> had or group by items to slow it down. Not so much the number of
> columns. Right?

At the outer level (which is not visible in this patch) it loops over
all columns in the select list, and then it looks up the indexes each
time. So the concern was that if the select list was * with a wide
table, looking up the indexes each time would be slow.

> Anyhow it sounds like I should try it on top of the other patch and
> see if it works. I assume it might still need some fixups to work
> with that other patch? Or do you expect it to just work?

There is some work necessary to integrate the two.


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Alex Hunsaker on 23 Jul 2010 13:17
On Fri, Jul 23, 2010 at 11:00, Alex Hunsaker <badalex(a)gmail.com> wrote:
> Alternatively we could make it
> work with just primary keys until the other patch gets in.  I think
> that makes sense, find that attached.  Thoughts?

*sigh*, find attached a version that removes talk of unique not null
constraints from the docs
From: Alex Hunsaker on 23 Jul 2010 13:00
On Sun, Jul 18, 2010 at 02:40, Peter Eisentraut <peter_e(a)gmx.net> wrote:
> On lör, 2010-07-17 at 11:13 -0600, Alex Hunsaker wrote:
>> So I would expect the more indexes you
>> had or group by items to slow it down.  Not so much the number of
>> columns.  Right?
>
> At the outer level (which is not visible in this patch) it loops over
> all columns in the select list, and then it looks up the indexes each
> time.  So the concern was that if the select list was * with a wide
> table, looking up the indexes each time would be slow.

Thanks for the explanation.

>> Anyhow it sounds like I should try it on top of the other patch and
>> see if it works.  I assume it might still need some fixups to work
>> with that other patch? Or do you expect it to just work?
>
> There is some work necessary to integrate the two.

I just read that patch is getting pushed till at least the next commit
fest: http://archives.postgresql.org/pgsql-hackers/2010-07/msg01219.php

Should we push this patch back to? Alternatively we could make it
work with just primary keys until the other patch gets in. I think
that makes sense, find that attached. Thoughts?

Note I axed the index not null attribute checking, I have not thought
to deeply about it other than if its a primary key it cant have non
null attributes.... Right? I may have missed something subtle hence
the heads up.
From: Peter Eisentraut on 24 Jul 2010 08:23
On fre, 2010-07-23 at 11:00 -0600, Alex Hunsaker wrote:
> I just read that patch is getting pushed till at least the next commit
> fest: http://archives.postgresql.org/pgsql-hackers/2010-07/msg01219.php
>
> Should we push this patch back to? Alternatively we could make it
> work with just primary keys until the other patch gets in. I think
> that makes sense, find that attached. Thoughts?

I was thinking the same thing.

> Note I axed the index not null attribute checking, I have not thought
> to deeply about it other than if its a primary key it cant have non
> null attributes.... Right? I may have missed something subtle hence
> the heads up.

Another open question I thought of was whether we should put the
dependency record on the pg_index row, or the pg_constraint row, or
perhaps the pg_class row. Right now, it is using pg_index, because that
was easiest to code up, but I suspect that once we have not-null
constraints in pg_constraint, it will be more consistent to make all
dependencies go against pg_constraint rather than a mix of several
catalogs.


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Alex Hunsaker on 26 Jul 2010 12:46
On Sat, Jul 24, 2010 at 06:23, Peter Eisentraut <peter_e(a)gmx.net> wrote:

> Another open question I thought of was whether we should put the
> dependency record on the pg_index row, or the pg_constraint row, or
> perhaps the pg_class row.  Right now, it is using pg_index, because that
> was easiest to code up, but I suspect that once we have not-null
> constraints in pg_constraint, it will be more consistent to make all
> dependencies go against pg_constraint rather than a mix of several
> catalogs.

I think for primary keys pg_index is OK. However for the not-null
case we have to use pg_constraint... So given that we end up having to
code that anyways, it seems like it will end up being
cleaner/consistent to always use the pg_constraint row(s). So +1 for
using pg_constraint instead of pg_index from me.

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: [HACKERS] Functional dependencies and GROUP BY
Next: [HACKERS] How to get permission to debug postgres?