On Wed, Oct 26, 2005 at 08:51:03PM -0400, Tom Lane wrote:
> I have some ideas in the back of my head about supporting
> cross-data-type hashing. Essentially this would require that the hash
> functions for two types be compatible in that they generate the same
> hash value for two values that woul
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:
> Aha!
> Figured out the "start" column wasn't the problem after all. The problem was
> the "stopp" column, which was timestamp on one side and date on the other...
Ah-hah.
> So, it can be fixed for this instance, but this feels a bit like the p
On Wed, Oct 26, 2005 at 07:53:02PM -0400, Tom Lane wrote:
> I don't think you're getting a correct reading for optup, but OID
> 2373 is timestamp = date:
>
> [...]
>
> My recollection is that there was no such operator in 7.4; probably in
> 7.4 the IN ended up using timestamp = timestamp which is
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:
> On Wed, Oct 26, 2005 at 07:06:15PM -0400, Tom Lane wrote:
>> AFAICS, subplan_is_hashable() is testing the same conditions in 7.4 and
>> HEAD, so this isn't clear. Want to step through it and see where it's
>> deciding not to hash?
> (gdb) print
On Wed, Oct 26, 2005 at 07:06:15PM -0400, Tom Lane wrote:
> AFAICS, subplan_is_hashable() is testing the same conditions in 7.4 and
> HEAD, so this isn't clear. Want to step through it and see where it's
> deciding not to hash?
Line 639, ie.:
635 if (!optup->oprcanhash || optup->
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:
> Any good ideas why 8.1 would refuse to do this, when 7.4 would do it? It does
> not matter how high I set my work_mem; even at 2.000.000 it refused to hash
> the subplan.
AFAICS, subplan_is_hashable() is testing the same conditions in 7.4 and
HE
Hi,
I finally found what I believe is the root cause for the hopeless
performance, after a lot of query rewriting:
> Subquery Scan mdb_effektiv_tilgang (cost=19821.69..4920621.69 rows=1
> width=48)
>Filter: ((NOT (hashed subplan)) AND (NOT (subplan)))
The problem here is simply that 8
On Thu, Oct 20, 2005 at 12:37:25AM -0400, Tom Lane wrote:
> That mdb_gruppekobling_transitiv_tillukning function looks awfully
> grotty ... how many rows does it return, and how long does it take to
> run by itself? How often does its temp table get vacuumed? A quick
> band-aid might be to use TR
On Thu, Oct 20, 2005 at 12:58:51AM -0400, Tom Lane wrote:
> As-is, it's not doing anything for you ... certainly not enforcing
> that the undergruppe_id be aktiv.
Oops, yes, that's a bug -- thanks for noticing. (It does not matter
particularily with the current data set, though.)
/* Steinar */
--
On Thu, Oct 20, 2005 at 12:37:25AM -0400, Tom Lane wrote:
> That mdb_gruppekobling_transitiv_tillukning function looks awfully
> grotty ... how many rows does it return, and how long does it take to
> run by itself? How often does its temp table get vacuumed? A quick
> band-aid might be to use TR
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:
> BEGIN
> INSERT INTO kortsys2.mdb_gruppekobling_temp
> SELECT overgruppe_id,undergruppe_id FROM gruppekobling gk
> JOIN gruppe g1 ON gk.overgruppe_id=g1.gruppe_id
> JOIN gruppe g2 ON gk.overgruppe_id=g2.grup
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:
> I'm using PostgreSQL 8.1 beta 3 (packages from Debian experimental), and I
> have a (rather complex) query that seems to take forever -- when the database
> was just installed, it took about 1200ms (which is quite good, considering
> that the 7.4
Hi,
I'm using PostgreSQL 8.1 beta 3 (packages from Debian experimental), and I
have a (rather complex) query that seems to take forever -- when the database
was just installed, it took about 1200ms (which is quite good, considering
that the 7.4 system this runs on today uses about the same time, b
13 matches
Mail list logo
