On 12 November 2015 at 13:44, Peter Geoghegan wrote:
> On Wed, Nov 4, 2015 at 6:30 PM, David Rowley
> wrote:
> >> Have you thought about *just* having an int64 pg_ltostr()? Are you
> >> aware of an appreciable overhead from having int32 callers just rely
> >> on a promotion to int64?
> >
> > I'd
On 11/22/2015 12:47 AM, Tom Lane wrote:
Andrew Dunstan writes:
I have just released version 4.16 of the PostgreSQL Buildfarm client
I updated my critters to 4.16, and since nothing much was happening in
git, decided to test by doing "run_build.pl --nosend --verbose --force"
manually on prair
On Sat, Nov 21, 2015 at 6:50 AM, Jeff Janes wrote:
> On Thu, Nov 19, 2015 at 6:44 AM, Masahiko Sawada
> wrote:
>> On Thu, Nov 19, 2015 at 5:54 AM, Jeff Janes wrote:
>>> On Wed, Nov 18, 2015 at 11:18 AM, Jeff Janes wrote:
I get an error when running pg_upgrade from 9.4 to 9.6-this
>>>
On 11/20/15 11:55 PM, Marko Tiikkaja wrote:
On 2015-11-21 06:52, Jim Nasby wrote:
On 11/20/15 11:12 PM, Marko Tiikkaja wrote:
On 2015-11-21 06:02, I wrote:
Here's a patch implementing this under the name num_nulls(). For
January's CF, of course.
I forgot to update the some references in the
On 11/21/15 12:49 AM, Pavel Stehule wrote:
I propose inversion function to pg_size_pretty function - like
pg_human_size.
Usage:
SELECT * FROM pg_class
WHERE pg_table_size(oid) > pg_human_size('2GB');
I'm not a big fan of the name, but +1 on the general idea.
Maybe pg_size_pretty(text)?
-
On 2015-11-22 18:29, Jim Nasby wrote:
Only if you know how many columns there already are.
Or does this not work if you hand it a row?
It "works" in the sense that it tells you whether the row is NULL or
not. I.e. the answer will always be 0 or 1.
.m
--
Sent via pgsql-hackers mailing li
2015-11-22 18:30 GMT+01:00 Jim Nasby :
> On 11/21/15 12:49 AM, Pavel Stehule wrote:
>
>>
>> I propose inversion function to pg_size_pretty function - like
>> pg_human_size.
>>
>> Usage:
>>
>> SELECT * FROM pg_class
>>WHERE pg_table_size(oid) > pg_human_size('2GB');
>>
>
> I'm not a big fan of
On 2015-11-22 18:30, Jim Nasby wrote:
On 11/21/15 12:49 AM, Pavel Stehule wrote:
I propose inversion function to pg_size_pretty function - like
pg_human_size.
Usage:
SELECT * FROM pg_class
WHERE pg_table_size(oid) > pg_human_size('2GB');
I'm not a big fan of the name, but +1 on the gene
On 11/22/15 11:34 AM, Marko Tiikkaja wrote:
On 2015-11-22 18:29, Jim Nasby wrote:
Only if you know how many columns there already are.
Or does this not work if you hand it a row?
It "works" in the sense that it tells you whether the row is NULL or
not. I.e. the answer will always be 0 or 1.
On 11/22/15 2:11 PM, Pavel Stehule wrote:
What about pg_size(text), pg_size(value bigint, unit text) ?
I like, though I'd make it numeric or float. pg_size(3.5, 'GB')
certainly seems like a reasonable use case...
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analy
On 2015-11-22 21:17, Jim Nasby wrote:
On 11/22/15 11:34 AM, Marko Tiikkaja wrote:
On 2015-11-22 18:29, Jim Nasby wrote:
Only if you know how many columns there already are.
Or does this not work if you hand it a row?
It "works" in the sense that it tells you whether the row is NULL or
not.
2015-11-22 21:19 GMT+01:00 Jim Nasby :
> On 11/22/15 2:11 PM, Pavel Stehule wrote:
>
>> What about pg_size(text), pg_size(value bigint, unit text) ?
>>
>
> I like, though I'd make it numeric or float. pg_size(3.5, 'GB') certainly
> seems like a reasonable use case...
yes, good note.
Regards
Pa
On Sun, Nov 22, 2015 at 8:16 AM, Masahiko Sawada wrote:
> Thank you for taking the time to review this patch!
> The updated version patch is attached.
I am skeptical about just copying the old page header to be two new
page headers. I don't know what the implications for this will be on
pd_lsn.
On Tue, Jul 28, 2015 at 04:04:29PM -0700, Joe Conway wrote:
> On 07/27/2015 05:34 PM, Joe Conway wrote:
> > On 07/27/2015 01:13 PM, Alvaro Herrera wrote:
> >> Hmm, these are not ACL objects, so conceptually it seems cleaner
> >> to use a different symbol for this. I think the catalog state
> >> an
Le 22 nov. 2015 21:29, "Pavel Stehule" a écrit :
>
>
>
> 2015-11-22 21:19 GMT+01:00 Jim Nasby :
>>
>> On 11/22/15 2:11 PM, Pavel Stehule wrote:
>>>
>>> What about pg_size(text), pg_size(value bigint, unit text) ?
>>
>>
>> I like, though I'd make it numeric or float. pg_size(3.5, 'GB')
certainly se
>
> What about pg_size_unpretty()?
>
I was going to suggest pg_size_ugly(), but unpretty does emphasize the
inverse (rather than opposite) nature of the function.
On Fri, Nov 20, 2015 at 2:58 PM, Peter Geoghegan wrote:
> The numbers speak for themselves here. I just want to be clear about
> the disadvantages of what I propose, even if it's well worth it
> overall in most (all?) cases.
There is a paper called "Critical Evaluation of Existing External
Sortin
On 08/26/2015 07:46 AM, Michael Paquier wrote:
On Wed, Aug 26, 2015 at 12:24 PM, Michael Paquier
wrote:
On Wed, Aug 26, 2015 at 10:57 AM, Tom Lane wrote:
[...]
So I think the way to move this forward is to investigate how to hold
the SSL config constant until SIGHUP in an EXEC_BACKEND build.
2015-11-22 23:54 GMT+01:00 Corey Huinker :
> What about pg_size_unpretty()?
>>
> I was going to suggest pg_size_ugly(), but unpretty does emphasize the
> inverse (rather than opposite) nature of the function.
>
"unpretty", "ugly" aren't good names
maybe pg_size_bytes or different approach
we ca
Hi All,
When the user attempts to make a connection with the database , the code
will look into various pg_catalog tables internally. However the user also
can query the pg_catalog tables. Is there a way to identify the user
requested (or typed query) vs the system requested (internal) queries?
A
On 18 November 2015 at 18:18, Konstantin Knizhnik wrote:
> But now SPI is used not only inside UDFs. It is also used in background
> workers. For example in receiver_raw, written by Michael Paquier (I lot of
> thanks Michael, understand logical replication without them will be much
> more diffic
21 matches
Mail list logo