> Chris Browne wrote:
>> Lukas Smith <[EMAIL PROTECTED]> writes:
>> > Bruce Momjian wrote:
>> >
>> >> * Flush cached query plans when the dependent objects change,
>> >> when the cardinality of parameters changes dramatically, or
>> >> when new ANALYZE statistics are available
>> >
>> > W
> Lukas Smith <[EMAIL PROTECTED]> writes:
>> Bruce Momjian wrote:
>>> * Flush cached query plans when the dependent objects change,
>>> when the cardinality of parameters changes dramatically, or
>>> when new ANALYZE statistics are available
>
>> Wouldn't it also make sense to flush a cached query
Lukas Smith <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> * Flush cached query plans when the dependent objects change,
>> when the cardinality of parameters changes dramatically, or
>> when new ANALYZE statistics are available
> Wouldn't it also make sense to flush a cached query plan whe
Marko Kreen wrote:
> > Maybe we should provide a backslash command in psql for secure
> > password entry, say, \password [username]. This would then ask for
> > the password through a somewhat secure, unlogged channel, encrypt
> > it, and send an ALTER ROLE command to the server.
>
> Letting creat
Chris Browne wrote:
> Lukas Smith <[EMAIL PROTECTED]> writes:
> > Bruce Momjian wrote:
> >
> >>* Flush cached query plans when the dependent objects change,
> >> when the cardinality of parameters changes dramatically, or
> >> when new ANALYZE statistics are available
> >
> > Wouldn't
Lukas Smith <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>
>> * Flush cached query plans when the dependent objects change,
>>when the cardinality of parameters changes dramatically, or
>>when new ANALYZE statistics are available
>
> Wouldn't it also make sense to flush a
Bruce Momjian wrote:
* Flush cached query plans when the dependent objects change,
when the cardinality of parameters changes dramatically, or
when new ANALYZE statistics are available
Wouldn't it also make sense to flush a cached query plan when after
execution it
Bruce Momjian writes:
> I think we are at a point that people running on systems with no int64
> support should not expect to get valid return values for >2 billion row
> COPY operations.
I agree, there's no need to work harder on this than changing the
datatype to uint64.
There are some places
Also, can I get a context diff for the patch? See the developers FAQ
for information on how our patch process works. Thanks.
---
Volkan YAZICI wrote:
> On Dec 16 08:47, Bruce Momjian wrote:
> > I think an int64 is the prop
Volkan YAZICI wrote:
> On Dec 16 08:47, Bruce Momjian wrote:
> > I think an int64 is the proper solution. If int64 isn't really
> > 64-bits, the code should still work though.
>
> (I'd prefer uint64 instead of an int64.) In src/include/c.h, in
> this or that way it'll assign a type for uint64, so
Jim C. Nasby wrote:
> Is cardinality the only thing we'd need to worry about? My idea was
> actually to track the amount of work normally required by a stored query
> plan, and if a query uses that plan but requires a very different amount
> of work it's a good indication that we either need to rep
Is cardinality the only thing we'd need to worry about? My idea was
actually to track the amount of work normally required by a stored query
plan, and if a query uses that plan but requires a very different amount
of work it's a good indication that we either need to replan or store
multiple plans
Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
> > Examining why psql won't do sensible stuff with COPY BINARY, I realized
> > that psql still uses PQgetline, which is marked obsolete since 7.4.
> > Is this intentional or just a "never reviewed because it works"?
>
> There wasn't an
On Dec 16 08:47, Bruce Momjian wrote:
> I think an int64 is the proper solution. If int64 isn't really
> 64-bits, the code should still work though.
(I'd prefer uint64 instead of an int64.) In src/include/c.h, in
this or that way it'll assign a type for uint64, so there won't
be any problem for bo
Christopher Kings-Lynne wrote:
> >>What I would like to see is some builtin functions that give me the
> >>table's DDL, just as pg_dump does. Extra nice would be complementary
> >>functions that also give me skeleton select statements for each table or
> >>view.
> >
> >
> > Yeah, what I first
15 matches
Mail list logo
