Daniel Migowski <dmigow...@ikoffice.de> writes:
> Am 03.08.2019 um 18:38 schrieb Tom Lane:
>> (After thinking a bit, I'm guessing that it seemed not to break because
>> your tests never actually exercised the generic-plan path, or perhaps
>> there was always a plancache invalidation before we tried to use the
>> query_list submitted by PrepareQuery. I wonder if this is telling us
>> something about the value of having PrepareQuery do that at all,
>> rather than just caching the raw parse tree and calling it a day.)
> Having PreparyQuery do _what_ exactly? Sorry, I am still learning how
> everything works here.
A plancache entry stores a raw parsetree (which is, at least
theoretically, an immutable representation of the parsed string),
and an analyzed-and-rewritten parsetree, and optionally a generic
plan tree. PrepareQuery is setting up the first two of these,
but only the raw parsetree is really essential ... or for that
matter, it might be possible to store just the source string
representation and re-parse that. It's all about space versus
speed tradeoffs. Our current philosophy is that if you bothered
to prepare a query it's because you want speed, but perhaps that
assumption needs rethinking.
> It seems like the patch crashes the postmaster when I use JOINSs
> directly in the PreparedStatement, not when I just place all the Joins
> in views. I will also look into this further.
Um. Now that I think about it, the regression tests probably don't
try to PREPARE any complex queries, so it's not impossible that
they just missed the fact that you were storing broken parse trees
for joins.
regards, tom lane
