I assume we have taken all the patches from here we want.
---
Teodor Sigaev wrote:
The 1C (http://www.1c.ru/) company kindly permits to publish a set of patches
we (Oleg and me) developed during our work on porting of the
Nice, thanks a lot.
Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] writes:
Just a freshing for clean applying..
http://www.sigaev.ru/misc/user_defined_typmod-0.11.gz
Applied with some revisions, and pg_dump support and regression tests
added.
regards, tom lane
Teodor Sigaev [EMAIL PROTECTED] writes:
Just a freshing for clean applying..
http://www.sigaev.ru/misc/user_defined_typmod-0.11.gz
Applied with some revisions, and pg_dump support and regression tests
added.
regards, tom lane
---(end of
Just a freshing for clean applying..
http://www.sigaev.ru/misc/user_defined_typmod-0.11.gz
Is any objections to commit?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
This is not responding to my concern. What you presented was an
Sorry, I see your point now.
Is that test enough? Or I should make more?
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
Teodor Sigaev [EMAIL PROTECTED] writes:
Just a freshing for clean applying..
http://www.sigaev.ru/misc/user_defined_typmod-0.11.gz
Is any objections to commit?
There's still a lot I don't particularly care for here (lack of
documentation being the biggest), but I'll make a pass at cleaning it
0.9 doesn't apply cleanly after Peter's changes, so, new version
http://www.sigaev.ru/misc/user_defined_typmod-0.10.gz
Teodor Sigaev wrote:
Perhaps an array of int4 would be better? How much
Done
http://www.sigaev.ru/misc/user_defined_typmod-0.9.gz
The patch needs more cleanup before
Perhaps an array of int4 would be better? How much
Done
http://www.sigaev.ru/misc/user_defined_typmod-0.9.gz
The patch needs more cleanup before applying, too, eg make comments
match code, get rid of unused keywords added to gram.y.
Cleaned.
--
Teodor Sigaev
Teodor Sigaev [EMAIL PROTECTED] writes:
Perhaps an array of int4 would be better? How much
Done
http://www.sigaev.ru/misc/user_defined_typmod-0.9.gz
The patch needs more cleanup before applying, too, eg make comments
match code, get rid of unused keywords added to gram.y.
Cleaned.
OK.
useful optimizations most of the time. Have you done any benchmarking
to find out what the cost is when the optimizations don't succeed?
Test runs on my notebook with PIII/512Mb, FreeBSD 6.1, postgres was compiled
with -O0 and --enable-debug --enable-cassert
Test results (ms)
Teodor Sigaev [EMAIL PROTECTED] writes:
useful optimizations most of the time. Have you done any benchmarking
to find out what the cost is when the optimizations don't succeed?
Test runs on my notebook with PIII/512Mb, FreeBSD 6.1, postgres was compiled
with -O0 and --enable-debug
The 1C (http://www.1c.ru/) company kindly permits to publish a set of patches
we (Oleg and me) developed during our work on porting of the '1C:Enterprise'
system to support the PostgreSQL database.
We would like to suggest to commit they to HEAD.
1) Typmod for user-defined types
Teodor Sigaev [EMAIL PROTECTED] writes:
2) ORDER BY .. [ NULLS ( FIRST | LAST ) ]
http://www.sigaev.ru/misc/NULLS_82-0.5.gz
i haven't looked at the other patches yet, but this one is just horrid :-(
Instead of creating a proper parse-tree representation of the NULLS
FIRST/LAST option, you've
Teodor Sigaev [EMAIL PROTECTED] writes:
3) Allow to use index for IS [NOT] NULL
http://www.sigaev.ru/misc/indexnulls_82-0.6.gz
Initially patch was developed by Martijn van Oosterhout
kleptog@svana.org.
But it's reworked and support of searching NULLS to GiST too. Patch
adds new
Teodor Sigaev [EMAIL PROTECTED] writes:
4) OR clauses optimizations
http://www.sigaev.ru/misc/OR_82-0.6.gz
This seems kinda ugly --- it looks very expensive and unlikely to find
useful optimizations most of the time. Have you done any benchmarking
to find out what the cost is when the
This has obvious semantic disdvantages (what if foo is an expensive
function?);
Agree.
but the real problem is that there's no way for the planner
to reason about ordering in this representation. This patch would
guarantee that an ORDER BY with the NULLS option couldn't use an
indexscan,
Teodor Sigaev [EMAIL PROTECTED] writes:
1) Typmod for user-defined types
http://www.sigaev.ru/misc/user_defined_typmod-0.7.gz
Patch is based on ideas from
http://archives.postgresql.org/pgsql-hackers/2004-06/msg00932.php
Teodor Sigaev [EMAIL PROTECTED] writes:
but the real problem is that there's no way for the planner
to reason about ordering in this representation. This patch would
guarantee that an ORDER BY with the NULLS option couldn't use an
indexscan, even if the index sorts nulls at the correct end.
This seems kinda ugly --- it looks very expensive and unlikely to find
useful optimizations most of the time. Have you done any benchmarking
to find out what the cost is when the optimizations don't succeed?
Yep, it's a big win with order and limit specified.
Let table (a,b) has index over
This one seems generally workable, but I really dislike the approach
that's been used for passing typmod arguments to the typmod_in function.
Representing them with an internal parameter means it'll be forever
impossible to write typmod functions in anything but C, which seems an
ugly
And what happens when we implement NULLS FIRST/LAST correctly? This is
really a poor choice of representation.
If it's just appending of indexscan's it's not a problem...
One thing I find questionable about this is the assumption that indexes
can support foo IS NULL and foo IS NOT NULL
On Mon, Dec 04, 2006 at 01:35:21PM -0500, Tom Lane wrote:
3) Allow to use index for IS [NOT] NULL
http://www.sigaev.ru/misc/indexnulls_82-0.6.gz
Initially patch was developed by Martijn van Oosterhout
kleptog@svana.org.
But it's reworked and support of searching NULLS to GiST
On Mon, Dec 04, 2006 at 02:04:26PM -0500, Tom Lane wrote:
Teodor Sigaev [EMAIL PROTECTED] writes:
1) Typmod for user-defined types
http://www.sigaev.ru/misc/user_defined_typmod-0.7.gz
Patch is based on ideas from
http://archives.postgresql.org/pgsql-hackers/2004-06/msg00932.php
23 matches
Mail list logo
