On Thu, Nov 14, 2013 at 2:37 AM, Janek Sendrowski wrote:
> Hi,
> I'm using the pg_trgm module,
> Is there a possibility not to convert one side of the string when comparing?
> I need a kind of reference string containing only certain trigrams.
> It's not possible to build every kind of string usin
> Well, off the top of my head I would of course be sure to build
> Postgres to take advantage of this:
>
> * Vectorization of the algorithm requires 32bit x 32bit -> 32bit integer
> * multiplication instruction. As of 2013 the corresponding instruction is
> * available on x86 SSE4.1 extensions
Commit fest 2013-11, the third commit fest (out of four) in the
PostgreSQL 9.4 development cycle, will start this Friday, November 15.
What is a commit fest?
https://wiki.postgresql.org/wiki/CommitFest
We always need more people to help review submitted patches. You don't
have to be an elite
On Thu, Nov 14, 2013 at 7:58 AM, Jayadevan wrote:
> Jeff Janes wrote
> > No. The checkpointer writes all data that was dirty as of a certain time
> > (the start of the checkpoint) regardless of how often it was used since
> > dirtied, and the background writer writes data that hasn't been used
>
Jeff Janes wrote
> No. The checkpointer writes all data that was dirty as of a certain time
> (the start of the checkpoint) regardless of how often it was used since
> dirtied, and the background writer writes data that hasn't been used
> recently, regardless of when it was first dirtied. Neither
On Wed, Nov 13, 2013 at 5:53 PM, Tatsuo Ishii wrote:
> It was good to see you in Japan.
Likewise.
> PostgreSQL Enterprise Consortium (non profit PostgreSQL related
> organization in Japan. http://www.pgecons.org) is about to inspect the
> performance impact of the checksum using High-end PC serv
Hi,
It was good to see you in Japan.
PostgreSQL Enterprise Consortium (non profit PostgreSQL related
organization in Japan. http://www.pgecons.org) is about to inspect the
performance impact of the checksum using High-end PC server (real 80
cores with 2TB memory). What in my mind is using pgbench
On Wed, Nov 13, 2013 at 4:39 PM, Michael Paquier
wrote:
> CRC16 is used.
Actually, subsequently another algorithm was introduced - see commit
43e7a668499b8a69a62cc539a0fbe6983384339c .
--
Regards,
Peter Geoghegan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
On Thu, Nov 14, 2013 at 12:58 AM, Scott Ribe
wrote:
> What checksum algorithm wound up in 9.3?
>
> (I found Simon Riggs 12/2011 submittal using Fletcher's, Michael Paquier's
> 7/2013 post stating CRC32 reduced to 16, and another post online claiming
> that it was changed from CRC before release
David Johnston writes:
> LPlateAndy wrote
>> When i call SELECT * FROM _function(IN TEXT) it is very slow on my WHERE
>> clause using LIKE($1||'%') but (run in error), very fast when LIKE('some
>> text'||'%')
> The index cannot be used for LIKE ($1 || '%') because there is no way the
> planner ca
On Wed, Nov 13, 2013 at 3:53 PM, Sergey Burladyan wrote:
> Jeff Janes writes:
>
> If I not mistaken, looks like lazy_scan_heap() called from
> lazy_vacuum_rel()
> (see [1]) skip pages, even if it run with scan_all == true,
> lazy_scan_heap()
> does not increment scanned_pages if lazy_check_needs_
Jeff Janes writes:
If I not mistaken, looks like lazy_scan_heap() called from lazy_vacuum_rel()
(see [1]) skip pages, even if it run with scan_all == true, lazy_scan_heap()
does not increment scanned_pages if lazy_check_needs_freeze() return false, so
if this occurred at wraparound vacuum it cann
LPlateAndy wrote
> When i call SELECT * FROM _function(IN TEXT) it is very slow on my WHERE
> clause using LIKE($1||'%') but (run in error), very fast when LIKE('some
> text'||'%')
The index cannot be used for LIKE ($1 || '%') because there is no way the
planner can guarantee the value of $1 isn't
Hi,
I have further found that it is only when passing the string in to the
function that the slow response occurs.
When i call SELECT * FROM _function(IN TEXT) it is very slow on my WHERE
clause using LIKE($1||'%') but (run in error), very fast when LIKE('some
text'||'%')
I have also created and
Hi,
I have created an index as follows:
(replace(lower(my_column), ' '::text, ''::text)
which i use in a WHERE clause against LIKE 'string%'
By using text_pattern_ops i get the index used provided i more than one
character is used in the string.
However, with the same SELECT query running wit
On Wed, Nov 13, 2013 at 7:29 AM, Миша Тюрин wrote:
>
> Hello!
> We are experiencing suspicious and very painful case in our
> top-business-critical database. We have only 7 weeks before emergency stop
> of the cluster cause wraparound task in autovacuum process can not be
> finished again and aga
On 13/11/13 20:21, Jeff Janes wrote:
> The planner uses the check constraints to reason about the relation
> between each partition separately and the query, not between the
> different partitions. So while it may be possible to know that all rows
> in 2013_4 must be greater than all in 2013_3, it
On Wed, Nov 13, 2013 at 5:26 AM, Torsten Förtsch
wrote:
> On 13/11/13 13:49, Gabriel Sánchez Martínez wrote:
> >> My question is, why does it then try to fetch one row from every other
> >> index? Can that be avoided without a lower bound on ts?
>
> > If you don't set a lower bound, since every ot
Hi,
I'm using the pg_trgm module,
Is there a possibility not to convert one side of the string when comparing?
I need a kind of reference string containing only certain trigrams.
It's not possible to build every kind of string using the function.
example:
Code: Alles auswählen
SELECT show_trgm('ab
On Tue, Nov 12, 2013 at 7:09 PM, Jayadevan wrote:
> Kevin Grittner-5 wrote
> > The checkpointer process is responsible for creating safe points
> > from which a recovery can begin; the background writer tries to
> > keep some pages available for re-use so that processes running
> > queries don't n
On 13 November 2013 17:17, Tiziano Valdemarin
wrote:
> Just a brief question:
>
> When I need to know the running pg version i do a
> SELECT version();
>
> and get this output:
> PostgreSQL 9.3.1, compiled by Visual C++ build 1600, 32-bit
>
> but I remember a 4 digit version numbering as
> 9.3.1-1
Tiziano Valdemarin wrote
> Just a brief question:
>
> When I need to know the running pg version i do a
> SELECT version();
>
> and get this output:
> PostgreSQL 9.3.1, compiled by Visual C++ build 1600, 32-bit
>
> but I remember a 4 digit version numbering as
> 9.3.1-1
>
> I can find this vers
Just a brief question:
When I need to know the running pg version i do a
SELECT version();
and get this output:
PostgreSQL 9.3.1, compiled by Visual C++ build 1600, 32-bit
but I remember a 4 digit version numbering as
9.3.1-1
I can find this version convention used i.e. on
http://www.ubuntuupda
What checksum algorithm wound up in 9.3?
(I found Simon Riggs 12/2011 submittal using Fletcher's, Michael Paquier's
7/2013 post stating CRC32 reduced to 16, and another post online claiming that
it was changed from CRC before release but not stating what it was changed to.)
--
Scott Ribe
scot
Hello, Tom! Thank you for so fast answer.
We did manual vacuum freeze with delay 10 also but unfortunately vacuum did
nothing with pg_class.relfrozenxid too.
Vacuum delay values like 10-40 work very well for many years in our production
cases.
> It's not terribly surprising that it's failing t
=?UTF-8?B?0JzQuNGI0LAg0KLRjtGA0LjQvQ==?= writes:
> We are experiencing suspicious and very painful case in our
> top-business-critical database. We have only 7 weeks before emergency stop of
> the cluster cause wraparound task in autovacuum process can not be finished
> again and again.
I'm be
Hello!
We are experiencing suspicious and very painful case in our
top-business-critical database. We have only 7 weeks before emergency stop of
the cluster cause wraparound task in autovacuum process can not be finished
again and again.
PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu, compiled b
On 11/13/2013 08:26 AM, Torsten Förtsch wrote:
On 13/11/13 13:49, Gabriel Sánchez Martínez wrote:
My question is, why does it then try to fetch one row from every other
index? Can that be avoided without a lower bound on ts?
If you don't set a lower bound, since every other table has dates bel
Chris Travers writes:
> I came across a query someone posted in the form of:
> SELECT *
> FROM [table_list]
> INHERITS ([table_list]);
> Naturally, never having seen this before I consulted the docs and there was
> nothing there that I could find. So I ran some tests and the syntax seems
> suppo
On 13/11/13 13:49, Gabriel Sánchez Martínez wrote:
>> My question is, why does it then try to fetch one row from every other
>> index? Can that be avoided without a lower bound on ts?
> If you don't set a lower bound, since every other table has dates below
> 2013-05-01, they have to be scanned to
Hello
2013/11/13 Dorian Hoxha
> Is it possible to:
>
> SELECT * FROM table
>
> But to return only non-null columns ?
>
no, it is not possible
Regards
Pavel Stehule
> Since i use psycopg2 with DictCursor (a hashtable) it's better for me when
> i don't have the column that to have it as NU
Is it possible to:
SELECT * FROM table
But to return only non-null columns ?
Since i use psycopg2 with DictCursor (a hashtable) it's better for me when
i don't have the column that to have it as NULL.
Thanks
On 11/13/2013 06:22 AM, Torsten Förtsch wrote:
Hi,
we have a table partitioned by time. Each month goes into a separate
child table. Primary key in each table is (underlying, ts). The
resulting index is perfect for ordering like in the query below. Each
child table has a constraint like:
CH
Hi,
On Wed, 2013-11-13 at 12:58 +0100, Alexander Farber wrote:
> The "man 5 pgbouncer" is slightly outdated then,
> it doesn't explain the auth_file format in detail:
>
>auth_file
>The name of the file to load user names and passwords from. The
> file format is the same as t
Thank you Devrim!
The "man 5 pgbouncer" is slightly outdated then,
it doesn't explain the auth_file format in detail:
auth_file
The name of the file to load user names and passwords from. The
file format is the same as the PostgreSQL
pg_auth/pg_pwd file, so this setti
Hi,
On Wed, 2013-11-13 at 12:28 +0100, Alexander Farber wrote:
> Hello,
>
> on CentOS 6.4 I'm moving from 8.4 to 9.3, but can not find the file
> /var/lib/pgsql/9.3/data/global/pg_auth which I need for the pg_bouncer.
>
> Does anybody please know where to find that file?
It was removed about 4
Hello,
on CentOS 6.4 I'm moving from 8.4 to 9.3, but can not find the file
/var/lib/pgsql/9.3/data/global/pg_auth which I need for the pg_bouncer.
Does anybody please know where to find that file?
My packages:
postgresql93-9.3.1-1PGDG.rhel6.x86_64
pgdg-centos93-9.3-1.noarch
postgresql93-libs-9.
Hi,
we have a table partitioned by time. Each month goes into a separate
child table. Primary key in each table is (underlying, ts). The
resulting index is perfect for ordering like in the query below. Each
child table has a constraint like:
CHECK(ts>= '2011-1-1' and ts<'2011-1-1'::DATE + inter
I came across a query someone posted in the form of:
SELECT *
FROM [table_list]
INHERITS ([table_list]);
Naturally, never having seen this before I consulted the docs and there was
nothing there that I could find. So I ran some tests and the syntax seems
supported.
It seems according to my test
39 matches
Mail list logo
