On Tue, Jun 14, 2016 at 08:20:12AM -0400, ''br...@momjian.us' *EXTERN*' wrote:
> > This has caused confussion in the past, see
> > https://www.postgresql.org/message-id/flat/561E749D.4090301%40socialserve.com#561e749d.4090...@socialserve.com
> >
> > > Right. Updated patch attached.
> >
> > I am
On Tue, Jun 14, 2016 at 08:37:12AM +, Albe Laurenz wrote:
> Bruce Momjian wrote:
> > However, for the wire protocol prepare/execute, how do you do EXPLAIN?
> > The only way I can see doing it is to put the EXPLAIN in the prepare
> > query, but I wasn't sure that works. So, I just wrote and tes
Bruce Momjian wrote:
> However, for the wire protocol prepare/execute, how do you do EXPLAIN?
> The only way I can see doing it is to put the EXPLAIN in the prepare
> query, but I wasn't sure that works. So, I just wrote and tested the
> attached C program and it properly output the explain inform
On Mon, Jun 13, 2016 at 04:29:26PM -0400, David G. Johnston wrote:
> On Mon, Jun 13, 2016 at 3:40 PM, br...@momjian.us wrote:
> I am not sure how we can improve things, but I wanted to clarify exactly
> what is happening.
>
>
> """
> Comparisons on non-uniformly-distributed
> columns an
On Mon, Jun 13, 2016 at 3:40 PM, br...@momjian.us wrote:
>
> > > Looking at how the code behaves, it seems custom plans that are _more_
> > > expensive (plus planning cost) than the generic plan switch to the
> > > generic plan after five executions, as now documented. Custom plans
> > > that ar
On Mon, Jun 13, 2016 at 01:26:04PM +, Albe Laurenz wrote:
> Bruce Momjian wrote:
> > Also, is it possible to do an EXPLAIN prepare() with the libpq/wire
> > protocol? I can't do PREPARE EXPLAIN, but I can do EXPLAIN EXECUTE.
> > However, I don't see any way to inject EXPLAIN into the libpq/wir
Bruce Momjian wrote:
> Also, is it possible to do an EXPLAIN prepare() with the libpq/wire
> protocol? I can't do PREPARE EXPLAIN, but I can do EXPLAIN EXECUTE.
> However, I don't see any way to inject EXPLAIN into the libpq/wire
> prepare case. Can you specify prepare(EXPLAIN SELECT)? (PREPARE
On Tue, Jun 7, 2016 at 06:52:15AM +, Albe Laurenz wrote:
> Bruce Momjian wrote:
> >> !distinct column values, a generic plan assumes a column equality
> >> !comparison will match 33% of processed rows. Column statistics
> >>
> >> ... assumes *that* a column equality comparison will ma
Bruce Momjian wrote:
>> !distinct column values, a generic plan assumes a column equality
>> !comparison will match 33% of processed rows. Column statistics
>>
>> ... assumes *that* a column equality comparison will match 33% of *the*
>> processed rows.
>
> Uh, that seems overly wordy.
On Mon, Jun 6, 2016 at 11:45 AM, Bruce Momjian *EXTERN*
wrote:
>
> One more thing --- there was talk of moving some of this into chapter
> 66, but as someone already mentioned, there are no subsections there
> because it is a dedicated topic:
>
> 66. How the Planner Uses Statistics.
> I
On Mon, Jun 6, 2016 at 07:19:37AM +, Albe Laurenz wrote:
> Bruce Momjian wrote:
> > OK, updated version attached. I added "potential" to the first
> > paragraph, and added "estimated cost" to the later part, fixed the
> > "cheaper than", and clarified that we add the plan time cost to the
> >
Bruce Momjian wrote:
> OK, updated version attached. I added "potential" to the first
> paragraph, and added "estimated cost" to the later part, fixed the
> "cheaper than", and clarified that we add the plan time cost to the
> non-generic plan, which is how it can be cheaper than the generic plan.
On Fri, Jun 3, 2016 at 08:27:38AM -0400, David G. Johnston wrote:
> This goes back to Bruce's motivation but as long as it goes into the
> internals
> section I have no problem adding material that someone felt was worth their
OK, updated version attached. I added "potential" to the first
para
On Fri, Jun 3, 2016 at 3:17 AM, Albe Laurenz
wrote:
>
> > I'd maybe go with something like this:
> >
> > All executions of a prepared statement having zero parameters will use
> the same plan so the planning
> > time taken during the first execution will be spread across all
> subsequent executio
David G. Johnston wrote:
> On Thu, Jun 2, 2016 at 9:56 PM, Bruce Momjian wrote:
>> In Postgres 9.2 we improved the logic of when generic plans are used by
>> EXECUTE. We weren't sure how well it would work, and the docs included
>> a vague description on when generic plans are chosen.
>>
>> I ha
On Thu, Jun 2, 2016 at 9:56 PM, Bruce Momjian wrote:
> In Postgres 9.2 we improved the logic of when generic plans are used by
> EXECUTE. We weren't sure how well it would work, and the docs included
> a vague description on when generic plans are chosen.
>
> I have gotten a few questions lately
On Thu, Jun 2, 2016 at 09:56:48PM -0400, Bruce Momjian wrote:
> In Postgres 9.2 we improved the logic of when generic plans are used by
> EXECUTE. We weren't sure how well it would work, and the docs included
> a vague description on when generic plans are chosen.
>
> I have gotten a few questio
In Postgres 9.2 we improved the logic of when generic plans are used by
EXECUTE. We weren't sure how well it would work, and the docs included
a vague description on when generic plans are chosen.
I have gotten a few questions lately about how prepared statements are
handled with multiple executi
18 matches
Mail list logo
